Adriano Lisboa Blog
Pensamentos, histórias e ideias.

OOD: DRY para humanos (com exemplos)

Este é o segundo artigo de uma série de 3 artigos sobre Object-Oriented Design (OOD), no primeiro discutimos sobre SOLID, sua utilidade e exemplificamos casos de violação e uso correto dos princípios.

Neste artigo vamos falar sobre o princípio DRY.

Afinal de contas, o que é DRY?

DRY é um acrónimo que foi introduzido por Andy Hunt e Dave Thomas em seu livro The Pragmatic Programmer e significa Don't repeat yourself (traduzindo ao pé da letra seria algo como: Não se repita).

DRY é um princípio de Object-Oriented Design (OOD) que tem como um de seus objetivos a eliminação da duplicação de lógica no código através de abstrações e a eliminação da duplicação de processos através de automações.

figura-1

Ao adicionar código não necessário à sua base de código você estará aumentando a quantidade de trabalho necessário para manter, evoluir e estender esse código no futuro. Não ter um entendimento de como se fazer abstrações de maneira correta é uma das principais causas para a repetição de código, a falta de tempo e pressão em projetos também contribuem (a famosa programação baseada em copy-paste).

Fazer tarefas repetitivas, como testes manuais que poderiam ser automatizados, builds que poderiam ser automatizadas e não executadas de forma manual também são considerados como duplicação, mas dessa vez duplicação de processos.

Exemplo de duplicação

figura-2
Figura 1: Exemplo de duplicação de código - Cortesia: Github Gist

No exemplo acima para buscar um artigo na base de dados por seu estado está duplicada em vários métodos (self.all_published, self.all_draft, self.all_spam), o mesmo acontece com a lógica para ver o estado do artigo que está duplicada nos métodos published?, draft? e spam?.

Exemplo de "DRYing"

figura-3
Figura 2: Exemplo de "DRYing" - Cortesia: Github Gist

Já no exemplo acima lógicas iguais estão agrupadas em métodos iguais, isso significa que se amanhã alguma regra de negócio para buscar artigos mudar, a pessoa desenvolvedora só terá que fazer alterações em 1 método (o mesmo ocorre com a lógica para descobrir o estado do artigo).


Duplicação é melhor que uma abstração errada?

Deixo aqui um artigo escrito pelo Marcos Brizeno trazendo pontos sobre duplicação versus uma abstração errada.


Agradecimentos

Um obrigado especial para Vitor Albuquerque e Marcos Brizeno por terem revisado o artigo antes de ser publicado :)


Referências

Author image
Brasil
I'm a Developer with good experience on design and architecture of software projects, agile methodologies, continuous integration, continuous deployment and continuous delivery.