Princípios, Padrões e Práticas para um Design Ágil na Java Magazine - Parte 2

Em Julho, saiu a segunda parte do meu artigo Princípios, Padrões e Práticas para um Design Ágil na revista Java Magazine edição 81,  e dando continuidade no artigo publicado na edição 80.

Para esta segunda parte, vamos abordar as diferenças entre a criação de uma arquitetura seguindo métodos tradicionais, como o Waterfall, e a criação de um Design Ágil a partir de ciclos iterativos de duas a três semanas. Além disso, veremos meios de identificar um software mal planejado através de alguns sintomas conhecidos como Design Smells.
Para tratar estes sintomas, abordaremos alguns princípios de Design OO, que são a base de muitos padrões de projeto e que são o produto de várias décadas de experiência com engenharia de software de não apenas um, mas de vários profissionais consagrados no ramo de tecnologia.
Veremos na prática alguns destes princípios, abordando todo o conceito teórico, expondo através de exemplos, sua utilidade e como eles se relacionam com alguns padrões de projeto, e por fim, veremos a aplicabilidade destes princípios nos cenários apropriados para cada um deles.
Para identificar se nosso sistema está com um bom design, Robert C. Martin, popularmente conhecido como Uncle Bob, apresentou alguns sintomas de design ruim, chamado de Design Smells (algo como Odores do Design). Estes sintomas permeiam a estrutura geral do software, e em seu livro Agile Software Development, Uncle Bob chegou a seguinte classificação:

• Rigidez
• Fragilidade
• Imobilidade
• Viscosidade (Pode ser 2 tipos: Viscosidade do Software e Viscosidade do ambiente)
• Complexidade Desnecessária
• Repetição Desnecessária
• Opacidade

Uma boa técnica para desenvolver um código expressivo é utilizar uma das principais ideias do Domain Driven Design, a Linguagem Ubíqua (ou Onipresente), proposta por Eric Evans. Esta técnica consiste em aplicar uma linguagem comum entre os desenvolvedores e analistas de negócio, utilizando os conceitos do modelo de domínio como forma primária de comunicação, fazendo com que ela seja aplicada tanto nos discursos entre os técnicos e os stakeholders quanto na documentação do sistema. Como consequência, fazemos com que os mesmos termos utilizados no domínio do negócio sejam expressos também no código, o que torna a comunicação mais transparente entre os times durante as discussões sobre o modelo do domínio.

Os sintomas citados acima, podem ser identificados em qualquer parte do sistema e são causados geralmente pela violação de alguns princípios da Programação Orientada a Objetos. Estes princípios, ainda que antigos, são pouco difundidos, mas essenciais para criar um bom Design em qualquer projeto orientado a objetos.
Os princípios que abordaremos no artigo são:

•  Princípio Aberto-Fechado (OCP – Open-Closed Principle);
•  Princípio DRY (Don’t Repeat Yourself);
•  Princípio da Responsabilidade Única (SRP – The Single Responsibility Principle);
•  Princípio da Substituição de Liskov (LSP – Liskov Substitution Principle);
•  Princípio do Conhecimento Mínimo (PLK – The Principle of Least Knowledge)

Diversão Garantida!