Um bom design de código começa por onde? [Parte 1 de 3]

Nos últimos meses tenho estudado, lido, dialogado com muita gente acerca de um bom design de código. E cada vez que investigo o assunto e busco colocar em prática ainda sinto que não é tão trivial assim. ( — E aqui eu falo de design bom, pq design tronxo muita gente já faz! ).

Quando pensei em escrever esse post, nada tirava da minha mente que o foco principal deveria ser essa sigla mágica: S.O.L.I.D, como se ela fosse salvar o design do nosso código. Porém, me ocorreu que eu deveria voltar nos meus "antepassados", voltar lá naqueles 3 princípios valiosos que seu profes de OO falava e vc não dava muita idéia, porque preferia entender conceitos mais rebuscados como Herança, Polimorfismo, Interfaces e outras coisas mais. Quais princípios eram esses? A tríplice Coesão, Acoplamento e Encapsulamento — esses 3 simples princípios se perderam na sua corrida carreira profissional, só eles já te ajudarão e muito na escrita de um bom design.

Todos esses conceitos que vc prestou mais atenção na aula de OO são bastante importantes também, no entanto se você pensá-los sobre a perspectiva do princípio da Coesão, Acoplamento e Encapsulamento irá arrasar muito mais no seu design.

Coesão, Acoplamento e Encapsulamento

Coesão

Pensar em coesão, é pensar na responsabilidade bem definida de classes, métodos, variáveis, pacotes, serviços, componentes e tudo mais que compõe um software e cujo seu nome exprima exatamente esta responsabilidade.

Isso parece tão óbvio. Certo? Certo! Mas é na prática que o bicho pega. Experimente dar nomes conceituais para as coisas e vai ver que tu pode entrar num fractal de opções. Quando falamos de assuntos do nosso cotidiano dar nomes é muito mais simples como dar o nome do seu gato novo( — Tu não vai chamar seu gato de Miau, só pq ele mia. Afinal tem 1 milhão de gatos por aí que fazem isso tb. Okay, pode ser que há alguém que o chame mesmo não sendo exclusividade do seu gato. Mas "Miau" é verbo, o nome do seu gato deve ser um substantivo!).

Dar nome significativo do que sua classe ou seu método vai fazer, enquanto nem a equipe de negócio descobriu o escopo do problema real é difícil. E até quando o escopo do problema está bem definido continua não sendo fácil dar o nome que você entenda daqui 1 semana, que sua equipe entenda imediatamente o que o código faz, que todos vocês entendam na próxima "sprint".

Então como minimizar essa dificuldade? Uma dica [Dica 1] que tenho recebido é que "Refactoring" taí para melhorar inclusive os nomes das classes, métodos, variáveis e etc. Não é fácil acertar de primeira, mesmo sendo um programador super experiente.

Outra dica [Dica 2] é trabalhar componentes de softwares como sendo pequenos fragmentos, ou seja, dar nome significativo para pequenas "porções" de código. Seguindo essa dica, ganhamos maior facilidade de manter partes menores e mais modulares; ganhamos também em reuso dessas pequenas partes;

Um exemplo bastante trivial, quando vamos fazer nossas classes de "View" não devemos ter um método que chama ImprimirSaldo(saldo) e o mesmo ter a responsabilidade de Calcular e Imprimir o saldo. Um método não deve cobrir diferentes responsabilidades. Além do mais, o método ImprimirSaldo(saldo) pode ser reusado quando um saldo for de uma conta corrente ou da conta poupança.

E a última dica [Dica 3] para alcançar coesão é: 
Faça a pergunta: este método vai ter que mudar por mais de um motivo com esta introdução que estou fazendo? Se sim, você está tirando a coesão do seu método. Da mesma forma faça a pergunta para as classes. Esta classe vai ter que mudar por mais de um motivo com esta introdução desse novo método/atributo? Se sim, crie outra classe para colocar o seu novo método/atributo.

E para finalizar essa primeira parte de Coesão: Quando não penso em coesão, o que acontece com os componentes do meu sistema? Pontos de reflexão:
Classes gigantes e difíceis de manter. 
Muitos métodos com diferentes contextos numa classe. 
Classes que não param de crescer.
Pouco reuso de métodos e classes.
Design ruim.
Dificuldade em testar o código.

Agora que sabemos sobre essa tal de coesão, avançamos num primeiro ponto em escrever código bom. A prática deles no seu dia a dia é que vai gerar essa melhoria que esta buscando.

Para ver exemplo obtendo Coesão dá uma olhada nesse Exemplo de Código Coeso e Não Coeso.

Próximo post Acoplamento!

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.