Saudações, leitores!
No mundo da Orientação a Objetos, uma dúvida um tanto quanto comum entre os desenvolvedores é identificar, selecionar e implementar padrões de projeto no desenvolvimento de um software. Se você também partilha dessa dúvida, acompanhe o artigo!
Design Patterns (Padrões de Projeto) são modelos orientados a objetos que podem ser empregados para simplificar ou solucionar determinadas ocasiões no software. O uso destes padrões provê uma melhor estrutura dos elementos do projeto, como a criação, estrutura e comportamento das classes.
Na parte 9 sobre dicas para desenvolvimento de um software, eu ressaltei que, para implementar Design Patterns, é importante possuir conhecimentos sólidos em programação orientada a objetos e um bom nível de abstração. Mesmo assim, às vezes nos encontramos em situações em que sabemos que um Design Pattern será útil, mas não sabemos especificamente qual deles.
O objetivo desse artigo é apresentar três dicas para ajudar a identificar o Design Pattern adequado para a solução, bem como o local no qual ele deve ser implementado no código-fonte.
1) UML
Uma linguagem de modelagem pode ser uma das melhores ferramentas para prever a aplicação de um Design Pattern. Os diagramas UML permitem expor os aspectos (tanto técnicos quanto de negócios) de um projeto de software, facilitando a visão como um todo. Um projetista pode, por exemplo, relacionar o conceito de um Design Pattern com a saída de um diagrama UML para encontrar a melhor implementação.
Para incrementar ainda mais essa dica, vou tentar apresentar alguns exemplos reais!
Imagine que, ao elaborar um Diagrama de Caso de Uso, foi possível verificar que dez casos de uso dependem de um evento em comum para realizar suas ações. Logo, poderíamos implementar um Observer e registrar estes dez casos de uso como “observadores” do evento. Dessa forma, quando o evento for disparado, os dez casos de uso serão notificados.
Em outra situação, suponha que o Diagrama de Atividades revelou que diferentes objetos são acessados ao realizar um cálculo de juros atualizados a cada ano. Para este caso, um Visitor seria adequado para acumular os valores conforme os objetos concretos são acessados, aliás, “visitados”.
2) Brainstorming
Em uma equipe de desenvolvimento, geralmente cada desenvolvedor tem ideias, conceitos e lógica diferentes dos outros. Além disso, é bem provável que cada um tenha conhecimentos em regras de negócio distintas. Dito isso, reunir todos os desenvolvedores para discutir a aplicação de Design Patterns nas funcionalidades do software é uma técnica interessante. No Scrum, esse brainstorming pode ser realizado na Sprint Planning, enquanto as funcionalidades do Sprint Backlog ainda estão sendo avaliadas.
O brainstorming permite que a identificação de Design Patterns seja feita de forma coletiva, ou seja, um dos desenvolvedores pode apresentar a natureza de uma determinada regra de negócio, enquanto o outro sugere a aplicação de um dos Design Patterns como solução. Em vista disso, podemos afirmar que essa técnica também promove a especialização dos desenvolvedores na área de Engenharia de Software.
Importante: essa dica foi elaborada baseada em fatos reais!
3) TDD
Quando um desenvolvedor programa com TDD, ele realiza várias refatorações no código-fonte, correto? Pois bem, essas refatorações podem gerar novos níveis de abstração no software, abrindo as portas para a aplicação de Design Patterns. Por exemplo, ao extrair um método de uma classe, criar heranças ou instanciar vários objetos, é possível observar as responsabilidades de cada classe e as dependências que existem entre elas. Baseado nessa abstração, o desenvolvedor pode aplicar alguns padrões de criação (Creational Design Patterns), como Abstract Factory, Builder ou Factory Method. Além da refatoração em si, ele estará contribuindo com a redução da complexidade, reutilização de código e minimizando a dependência entre classes.
Muitas vezes, durante a refatoração, o desenvolvedor acaba por aplicar algum Design Pattern sem notar. Algum tempo depois, quando o desenvolvedor toma conhecimento da existência do Design Pattern, imediatamente percebe que já o utilizou antes, mesmo que implicitamente. Isso já aconteceu comigo com o Singleton. Claro, não implementei exatamente como a teoria sugere, mas o cenário e a ideia foram praticamente os mesmos.
Antes de finalizar o artigo, gostaria também de destacar que, para a aplicação correta e adequada de Design Patterns, é desejável que o desenvolvedor saiba o objetivo principal de cada um deles. Não é preciso saber implementá-los de cabeça, mas só pelo fato de conhecer o propósito de cada um deles já é o suficiente! Pra ser sincero, eu ainda estou nessa luta para compreender a finalidade de todos eles…
Abraço, pessoal!
Até a próxima semana.
