Não Se Repita (DRY Don’t Repeat Yourself)

Não é só sobre o desperdício.

Quando estamos desenvolvendo nosso código, implementando novas funcionalidades, principalmente quando não há uma fase de planejamento (design) prévio detalhado, podemos nos encontrar na situação de estar repetindo código durante esse processo. É importante, porém, remediarmos rapidamente essa situação. É justamente aqui que o princípio DRY pode nos ajudar a reconhecer tal importância.

O princípio DRY, sigla em inglês para Don’t Repeat Yourself (Não Se Repita em livre tradução), criado por Andy Hunt, propõe que cada funcionalidade em um projeto deve ser representada apenas uma vez. Pode ser aplicado no desenvolvimento de código, modelos de dados, testes, etc. Cá para nós, repetição é desperdício em qualquer sistema inteligente. Menos é mais e quanto mais simples, enxuto e reaproveitado o código for, melhor! Quem, em algum momento da sua vida, nunca testemunhou outros ou a si mesmos mudando várias classes, páginas, ou arquivos, durante a manutenção de algum sistema, apenas para consertar um único detalhe? Este é o abismo que a repetição, sem a devida refatoração ou planejamento, nos proporciona. Sem atenção e zelo pelo código a entropia entra em ação e o caos se instala fácil e rapidamente, muitas vezes silenciosamente, até que venha alardear num momento posterior durante um bug, implementação de novas funcionalidades ou qualquer outra manutenção, trazendo aquele demorado (re)trabalho e, no final das contas, prejuízo. Com a reutilização de código você faz a modificação em um único lugar para o efeito refletir em todas as outras partes! Daí, pessoal, não tem desvantagem.

Soluções para este problema são simples e geralmente requerem apenas encapsulamentos básicos, colocar a funcionalidade em uma única função, propriedade de classe, ou então abstrair toda a funcionalidade em uma única classe base para que as classes derivadas herdem dela. Na modelagem de dados um caso simples poderia ser o de termos as tabelas Jogador, Técnico e Juiz. Todas estas entidades possuem dados diferentes entre si (por isso precisamos de três tabelas diferentes), mas ainda assim contêm Nome, Idade e País de Origem. Ao invés de termos os dados Nome, Idade e País de Origem repetindo nas tabelas três tabelas, uma solução seria criarmos a entidade Pessoa, com os dados repetitivos, e usarmos a chave primária dessa tabela como chave estrangeira nas outras tabelas. Ou seja, estamos herdando dados da tabela base Pessoa.

A aplicação deste princípio é sem dúvida sensata e benéfica, pois facilita o trabalho do programador, ganha tempo e flexibilidade para o projeto, e o mais importante: o cliente fica feliz ao saber que seu sistema é robusto e não uma torre de cartas! :)

Espero que tenham gostado deste rápido bate-papo. Nos falamos no próximo artigo, fiquem com Deus. Um abraço!