Insights de código limpo – Classes

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:

classes

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

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s