Hoje em Insights de código limpo trago algumas reflexões sobre Classes.
No livro Código Limpo – Habilidades práticas do agile software, este é um capítulo escrito pelo tio Bob e Jeff Langr.
Neste capítulo Bob e Jeff falam sobre alguns pontos importantes para a escrita de classes limpas, são eles:
Organização de classes
Nesta parte do livro são explicadas algumas convenções para a linguagem Java, mas como não quero me ater a uma linguagem específica, iremos direto para as questões mais genéricas, independente da linguagem escolhida.
Encapsulamento
É importante que as classes mantenham suas variáveis e funções utilitárias privadas, ou seja, estas devem fazer parte de seu domínio. Algumas vezes um teste precisa acessar uma destas variáveis ou funções, quando isso é necessário, deve ser feito de forma que as variáveis ou funções estejam protegidas. Mas sempre que possível a privacidade deve ser mantida. Perder o encapsulamento deve ser sempre o último recurso.
As classes devem ser pequenas
As classes, como as funções, devem ser pequenas, mas de outra perspectiva. Em vez de medir o tamanho pelo número de linhas, deve-se contar o número de responsabilidades de uma classe e esse número deve levar para o mínimo de responsabilidades possível. Idealmente uma classe só tem uma responsabilidade. Além disso, o nome da classe deve descrever a responsabilidade da qual ela trata.
O princípio da responsabilidade única
Uma classe ou módulo deve ter uma e somente uma razão para mudar. Tentar identificar responsabilidades (razões para mudar) frequentemente ajuda a reconhecer melhores abstrações no código. O princípio da responsabilidade única é um dois conceitos mais importantes de projetos orientados à objetos. E ainda, classes pequenas colaboram umas com as outras para atingir o comportamento desejado do sistema.
Coesão
Uma classe na qual cada variável é utilizada por somente um método é coesa ao máximo.
Manter a coesão resulta em muitas classes pequenas
Neste caso o título é auto-explicativo, mas, um ponto importante é que quando uma refatoração está sendo feita para, por exemplo, transformar uma classe grande em várias classes menores, testes a nível de unidade podem ajudar, pois, a cada pequena classe que é extraída da classe maior, os testes podem ser executados, garantindo que o comportamento do sistema não se alterou.
Organizar para a mudança
Sistemas devem estar preparados para a mudança, pois ela é inevitável. E quando tal mudança ocorre, deve-se garantir que o sistema continua funcionando.
Da perspectiva de testes, a organização em classe menores torna fácil a tarefa de verificar a lógica do sistema, uma vez que as classes estão isoladas umas das outras.
Nesta organização para a mudança, além do princípio da responsabilidade única, outro princípio importante é o Open-Closed Principle. Ou seja, as classes devem ser abertas para extensão, mas fechadas para modificações.
Isolar de mudanças
Um ponto relevante sobre o isolamento de mudanças é outro princípio importante, o princípio da inversão de dependência, o qual em essência diz que as classes devem depender de abstrações e não de detalhes concretos.
Agradecimentos especiais ao Luiz Amorim, pela revisão de última hora.
Gostou? Semana que vem tem o próximo capítulo. Ainda assim, recomendo a leitura do livro original.
Quer conversar a respeito do assunto? Deixe um comentário.
Já conhece o site da minha marca pessoal? Ainda não?
Acessa aí: walmyr-filho.com
TALKING ABOUT TESTING 