Uma forma de ensinar OOP para programadores procedurais na década de 80 com cartões!

Este e um texto traduzido livremente!

Kent Beck, Apple Computer, Inc.
Ward Cunningham, Wyatt Software Services, Inc.

Dos Anais da Conferência OOPSLA'89,
de 1 a 6 de outubro de 1989, Nova Orleans, Louisiana
E da edição especial do SIGPLAN Notices
Volume 24, Número 10, outubro de 1989

Introdução

É difícil introduzir programadores procedimentais novatos e experientes à perspectiva antropomórfica necessária para o projeto orientado a objetos. Apresentamos os cartões CRC, que caracterizam os objetos pelo nome da classe, responsabilidades e colaboradores, como forma de dar aos alunos uma experiência direta dos objetos. Descobrimos que essa abordagem é bem-sucedida ao ensinar aos programadores novatos os conceitos de objetos e ao apresentar aos programadores experientes projetos complicados existentes.

1. Problema

O problema mais difícil no ensino de programação orientada a objetos é fazer com que o aluno desista do conhecimento global de controle que é possível com programas procedurais e confie no conhecimento local de objetos para realizar suas tarefas. Projetos novatos estão repletos de regressões ao pensamento global: variáveis globais gratuitas, ponteiros desnecessários e confiança inadequada na implementação de outros objetos.
Como aprender sobre objetos requer uma mudança na abordagem geral, ensinar objetos reduz-se a ensinar o design de objetos. Nós nos concentramos em design, quer estejamos ensinando conceitos básicos para novatos ou as sutilezas de um design complicado para programadores de objetos experientes.

Em vez de tentar tornar o design de objetos o mais parecido possível com o design processual, descobrimos que a maneira mais eficaz de ensinar a maneira idiomática de pensar com objetos é imergir o aluno na "objetividade" do material. Para fazer isso, devemos remover o máximo possível de material familiar, esperando que detalhes como sintaxe e operação do ambiente de programação sejam captados com rapidez suficiente, uma vez que os fundamentos tenham sido totalmente compreendidos.

É nesse contexto que descreveremos nossa perspectiva sobre o design de objetos, sua manifestação concreta, os cartões CRC (para Classe, Responsabilidade e Colaboração) e nossa experiência no uso desses cartões para ensinar os fundamentos e as sutilezas do pensamento com objetos.

2. Perspectiva

Projetos procedimentais podem ser caracterizados em um nível abstrato como tendo processos, fluxos de dados e armazenamentos de dados [1], independentemente da linguagem de implementação ou do ambiente operacional. Queríamos criar um conjunto semelhante de princípios fundamentais para projetos de objetos. Estabelecemos três dimensões que identificam o papel de um objeto em um design: nome da classe, responsabilidades e colaboradores.
O nome de classe de um objeto cria um vocabulário para discutir um projeto. De fato, muitas pessoas observaram que o projeto de objeto tem mais em comum com o projeto de linguagem do que com o projeto de programa processual. Incentivamos os alunos (e passamos um tempo considerável enquanto projetamos) a encontrar o conjunto certo de palavras para descrever nossos objetos, um conjunto que seja internamente consistente e evocativo no contexto do ambiente de design mais amplo.

As responsabilidades identificam os problemas a serem resolvidos. As soluções existirão em muitas versões e refinamentos. Uma responsabilidade serve como um identificador para discutir possíveis soluções. As responsabilidades de um objeto são expressas por um punhado de frases verbais curtas, cada uma contendo um verbo ativo. Quanto mais puder ser expresso por essas frases, mais poderoso e conciso será o design. Mais uma vez, procurar as palavras certas é um uso valioso do tempo durante o design.

Uma das características distintivas do design de objetos é que nenhum objeto é uma ilha. Todos os objetos estão em relação com outros, de quem dependem para serviços e controle. A última dimensão que usamos na caracterização de projetos de objetos são os colaboradores de um objeto. Nomeamos objetos colaboradores que enviarão ou receberão mensagens no decorrer do cumprimento de responsabilidades. A colaboração não é necessariamente uma relação simétrica. Por exemplo, em Smalltalk-80 [2] , View e Controller operam quase iguais (veja o exemplo abaixo), enquanto OrderedCollection oferece um serviço com pouca consideração ou mesmo consciência de seu cliente.

Ao longo deste artigo, deliberadamente obscurecemos a distinção entre classes e instâncias. Essa informalidade não é tão confusa quanto pode parecer porque a concretude de nosso método substitui a nomeação de instâncias. Isso também torna nosso método de ensino independente de uma linguagem baseada em classe ou protótipo ser usada.

3. Cartões CRC
O segundo autor inventou os cartões CRC em resposta à necessidade de documentar as decisões de design colaborativo. Os cartões começaram como uma pilha HyperCard [3] que fornecia indexação automática aos colaboradores, mas foram movidos para sua forma atual para resolver problemas de portabilidade e independência do sistema.
Como nosso trabalho anterior na documentação da colaboração de objetos [4] , os cartões CRC representam explicitamente vários objetos simultaneamente. No entanto, em vez de simplesmente traçar os detalhes de uma colaboração na forma de envio de mensagens, os cartões CRC colocam o foco do designer na motivação para a colaboração, representando (potencialmente) muitas mensagens como uma frase de texto em inglês.

Figura 1. Um cartão de índice de Colaborador de Responsabilidade de Classe (CRC)

Como os usamos atualmente, todas as informações de um objeto são escritas em um cartão de índice de 4" x 6". Estes têm as vantagens de serem baratos, portáteis, prontamente disponíveis e familiares. A Figura 1 mostra um cartão idealizado. O nome da classe aparece sublinhado no canto superior esquerdo, uma lista de responsabilidades aparece abaixo dela nos dois terços esquerdos do cartão e a lista de colaboradores aparece no terço direito.

Figura 2. Cartões CRC descrevendo as responsabilidades e colaborações do Model, View e Controller de Smalltalk.

A Figura 2 mostra um exemplo obtido da imagem Smalltalk-80, a muito incompreendida estrutura de interface do usuário Model, View e Controller. Mostramos deliberadamente apenas uma parte das responsabilidades que cada um desses objetos assume para clareza de exposição. Observe que os cartões são colocados de modo que View e Controller se sobreponham (o que implica em estreita colaboração) e colocados acima do Model (o que implica supervisão). Descobrimos que esses e outros agrupamentos informais ajudam na compreensão de um projeto. As partes, por exemplo, muitas vezes são dispostas abaixo do todo. Da mesma forma, os refinamentos de uma abstração podem ser coletados e tratados como uma única pilha de cartas com a carta mais abstrata no topo, onde ela pode representar o resto.

O design com os cartões tende a progredir de conhecidos para desconhecidos, em vez de de cima para baixo ou de baixo para cima. Observamos duas equipes chegando essencialmente ao mesmo projeto por meio de sequências quase opostas, uma começando com drivers de dispositivo e a outra com modelos de alto nível. O problema exigia um certo conjunto de capacidades que ambas as equipes descobriram ao cumprir os requisitos do projeto.

Sugerimos direcionar um projeto para a conclusão com o auxílio de cenários de execução. Começamos com apenas uma ou duas cartas óbvias e começamos a jogar "e se". Se a situação exigir uma responsabilidade ainda não coberta por um dos objetos, adicionamos a responsabilidade a um dos objetos ou criamos um novo objeto para tratar dessa responsabilidade. Se um dos objetos ficar muito confuso durante esse processo, copiamos as informações de seu cartão para um novo cartão, buscando maneiras mais concisas e poderosas de dizer o que o objeto faz. Se não for possível reduzir ainda mais as informações, mas o objeto ainda for muito complexo, criamos um novo objeto para assumir algumas das responsabilidades.

Encorajamos os alunos a pegar o cartão cujo papel estão assumindo enquanto "executam" um cenário. Não é incomum ver um designer com um cartão em cada mão, agitando-o, fazendo uma forte identificação com os objetos ao descrever sua colaboração.

Ressaltamos a importância de criar objetos não para atender às míticas necessidades futuras, mas apenas sob as demandas do momento. Isso garante que um projeto contenha apenas o máximo de informações que o designer experimentou diretamente e evita a complexidade prematura. Trabalhar em equipe ajuda aqui porque um designer preocupado pode influenciar os membros da equipe sugerindo cenários voltados especificamente para suspeitas de fraquezas ou omissões.

A capacidade de organizar rapidamente e endereçar fichas espacialmente é mais valiosa quando um projeto está incompleto ou mal compreendido. Vimos designers referirem-se repetidamente a um cartão que pretendiam escrever, apontando para onde o colocariam quando concluído.

4. Experiência

Um dos contextos em que utilizamos os cartões CRC é uma aula de três horas intitulada "Pensando com Objetos", destinada a profissionais de computação que já programaram, mas cujas funções não necessariamente envolvem programação diária. A aula prossegue apresentando um exemplo de fluxo de dados (uma escola, com processos de ensino e administração) que é então reformulado em termos de objetos com responsabilidades e colaboradores (como Professor, Zelador e Diretor). A turma então forma duplas e passa uma hora projetando os objetos em um caixa eletrônico, exercício escolhido pela familiaridade de todos com o aplicativo e sua pronta decomposição em objetos para controlar os aparelhos, comunicar-se com o banco de dados do banco central e controlar o usuário. interface. (Consulte o apêndice para obter uma solução de exemplo.
Ao ensinar este curso a mais de uma centena de alunos, não encontramos ninguém que fosse incapaz de completar o exercício sem ajuda, embora um par em cada classe geralmente precise de algumas dicas para começar. Embora não tenhamos feito estudos de acompanhamento, a classe é considerada um recurso valioso na empresa e ainda é bem atendida com uma longa lista de espera quase um ano após seu início.

Também pedimos aos programadores de objetos qualificados que tentassem usar cartões CRC. Nossa experiência pessoal sugere um papel para os cartões na engenharia de software, embora ainda não possamos reivindicar uma metodologia completa (outros [5][6] desenvolveram metodologias mais completas que podem tirar proveito dos métodos CRC). Sabemos de um caso em que os cartões acabados foram entregues a um cliente como documentação de design (parcial). Embora a equipe que produziu os cartões tenha ficado bastante satisfeita com o design, o destinatário não conseguiu entender os cartões fora do contexto.

Outra experiência ilustra a importância do contexto estabelecido pelo manuseio e discussão das cartas. Tínhamos filmado designers experientes resolvendo um problema semelhante ao do caixa eletrônico. Nossa colocação de câmera tornou os cartões e as mãos dos designers visíveis, mas não a escrita nos cartões. Os espectadores da fita não tiveram problemas para acompanhar o desenvolvimento e muitas vezes pediram que a fita fosse interrompida para que pudessem expressar suas opiniões. Os momentos mais marcantes ocorreram quando a explicação do espectador exigia que ele apontasse para um cartão borrado na imagem congelada na tela.

Finalmente, usamos cartões CRC para explicar projetos complexos. Alguns minutos de introdução são suficientes para preparar o público para uma apresentação baseada em cartão. Os cartões podem ser feitos com antecedência ou escritos na hora. Este último permite que a complexidade de um projeto seja revelada lentamente, um processo relacionado ao "gerenciamento de mentiras" de Dave Thomas. Os cartões estão sendo usados como acessórios para ajudar a contar uma história de computação. Os cartões permitem que seja contado sem recorrer à sintaxe ou idioma da linguagem de programação.

5. Conclusão

Tomando nossa perspectiva como base, damos a novatos e programadores experientes uma experiência de aprendizado que lhes ensina algo valioso sobre objetos. Os cartões CRC dão ao aluno que nunca encontrou objetos uma compreensão física da objetividade e os prepara para entender o vocabulário e os detalhes de idiomas específicos. Os cartões CRC também fornecem uma experiência útil e convincente com objetos para aqueles que aprenderam os mecanismos dos objetos, mas ainda não perceberam seu valor.
Ragu Raghavan [7] disse que na mudança para objetos os programadores fortes se tornam mais fortes, mas os programadores mais fracos são deixados para trás. Usando os cartões em configurações de grupo, descobrimos que mesmo os programadores mais fracos, sem uma compreensão profunda dos objetos, poderiam contribuir para projetos de objetos. Especulamos que, como os projetos são muito mais concretos e a relação lógica entre os objetos é mais fácil de entender, avaliar e modificar um projeto.

Ficamos surpresos com o valor de mover fisicamente as cartas. Quando os alunos pegam um objeto, eles parecem se identificar mais prontamente com ele e estão preparados para lidar com o restante do design de sua perspectiva. É o valor dessa interação física que nos levou a resistir à informatização dos cartões.

É exatamente esse problema – integrar os cartões com metodologias de design mais amplas e com ambientes de linguagem específicos – que acreditamos ser o mais promissor para o futuro. A necessidade de reter o valor da interação física aponta para a necessidade de um novo tipo de interface de usuário e ambiente de programação muito além do que temos hoje, pois nossos sistemas atuais estão além dos ambientes orientados a ferramentas do passado.

Referências
[1] DeMarco, T.: Análise Estruturada e Especificação de Sistema, Yourdon, 1978.
[2] Imagem Smalltalk-80, Xerox Corp, 1983.

[3] Manual do HyperCard, Apple Computer Inc.

[4] Cunningham, W. e Beck, K.: "A Diagram for Object-Oriented Programs", em Proceedings of OOPSLA-86, outubro de 1986.

[5] Wirfs-Brock, R. e Wilkerson, B. "Design orientado a objetos: uma abordagem voltada para a responsabilidade", submetido à OOPSLA '89.

[6] Reenskaug, T.: "A Methodology for the Design and Description of Complex, Object-Oriented Systems", relatório técnico, Centro de Pesquisa Industrial, Oslo, Noruega, novembro de 1988.

[7] Raghavan, R.: "Panel: Experiences with Reusability", in Proceedings of OOPSLA '88, outubro de 1988.