Padrões Command e outros Patterns na prática

Os design patterns (padrões de design) sempre fascinaram os desenvolvedores de software, mas o verdadeiro conhecimento de sua aplicabilidade e consequências tem eludido muitos deles também. As várias soluções que foram criadas e aplicadas para resolver problemas semelhantes foram estudadas ao longo do tempo por desenvolvedores e arquitetos experientes. Um movimento começou lentamente a catalogar tais soluções testadas pelo tempo e bem-sucedidas, que serviram de modelo para o design de um software. A aplicabilidade dos padrões de design apresentou maturidade (mesmo que a superestrutura seja um risco percebido) na arquitetura da solução (em termos de estabilidade, consistência, manutenção e extensibilidade) e se tornou uma habilidade básica para desenvolvedores e arquitetos sérios. É igualmente importante compreender a evolução dos padrões, idiomas, linguagens de programação e movimentos que levaram à padronização desses planos agnósticos da tecnologia, que constituem a base do desenvolvimento de aplicações corporativas hoje.

OOP

OOP é um modelo de programação que supostamente combina estrutura (dados) e comportamento (métodos) para fornecer funcionalidades de software. O mesmo foi um contraste acentuado em relação ao modelo de programação processual, que estava principalmente em voga quando o modelo OOP ganhou proeminência. A principal unidade de composição em um modelo de programação processual é um procedimento (principalmente uma função com efeitos colaterais). Os dados são alimentados em uma série de procedimentos que constituem o processo ou algoritmo em um contexto de solução. No caso do OOP, os dados e funções relacionadas são representados juntos como uma classe, que atua como uma unidade fundamental no modelo de programação. Esquematicamente temos a representação demonstrada na Listagem 1.

Listagem 1. Representação de uma classe.

Como programador, podemos criar muitas instâncias de uma classe durante a execução de um programa. Uma vez que a classe encapsula dados e suas operações associadas para fornecer uma entidade coerente, os problemas (ou, em vez disso, efeitos colaterais) associados a variáveis/dados globais (sendo usados como carga útil para os procedimentos) desapareceram de repente. Isso ajudou a gerenciar a complexidade do desenvolvimento de um grande software.

O OOP revolucionou a forma como os programadores modelaram o domínio do problema, com composições de classes alavancando encapsulamento, associação, herança e polimorfismo. Além disso, com a flexibilidade para modelar hierarquias (que representam de perto o domínio do problema) com facilidade, tornou-se natural que os desenvolvedores pensassem em termos de objetos.

A Microsoft inicialmente colocou suas apostas em uma estratégia de arquitetura corporativa chamada Windows DNA, centrada no DCOM (Distributed Component Object Model). O advento e a tração do modelo de programação Java forçaram a Microsoft a reformular sua estratégia, então eles decidiram criar uma plataforma de máquina virtual chamada .NET. A plataforma .NET foi lançada em 2002, e foi apelidada de Java da Microsoft. O velho adágio de “imitação é a forma mais sincera de lisonja” foi ecoada pelos especialistas da indústria.

Por que precisamos de Design Patterns?

Escrever código de qualidade de forma consistente não é fácil sem alguns princípios fundamentais absorvidos pelos desenvolvedores. Diversos autores tentaram assimilar os princípios fundamentais de desenvolvimento de software, que ajudam a escrever um código de qualidade, a saber:

• KISS: Keep It Simple, Stupid (Mantenha simples, estúpido);
• DRY: Don’t Repeat Yourself (Não se repita);
• YAGNI: You aren’t gonna need it (Você não vai precisar disso);
• Acoplamento baixo: minimize o acoplamento entre as classes;
• Princípios SOLID: princípios para uma melhor OOP.

O primeiro item da lista, é um dos preferidos da comunidade. Esta máxima é importante porque, na maioria das vezes, os desenvolvedores caem na armadilha de escrever código de forma genérica para extensibilidade injustificada. Embora inicialmente pareça atraente, as coisas ficam sem limites. A complexidade acidental introduzida na base do código para atender a cenários improváveis, muitas vezes reduz a legibilidade e a capacidade de manutenção. O princípio KISS pode ser aplicado, inclusive, a esforços humanos do dia a dia como um todo.

Já em relação ao DRY, ao “não” fazer isso, corremos grandes riscos de inundar a base do código, induzir a erros sutis e tornar as coisas realmente difíceis de mudar. Ao seguir a máxima DRY em todos os estágios de desenvolvimento, podemos evitar esforços adicionais e tornar o código consistente. O oposto de DRY é escrever tudo duas vezes (WET, de "