Design Patterns – Padrões de Projetos

Basicamente, trata-se de práticas consagradas para evitar proliferação de classes pelo sistema. Maneiras mais inteligentes para o agrupamento e reutilização dos objetos, trazendo soluções mais eficazes, eficientes e com menor consumo de memória (algumas vezes).

Bom, comecei a estudar este assunto não dando muito credibilidade em sua aplicabilidade. Cheguei a conversar com meu consultor de “reclamações aleatórias”, Denysson Mota (blog ao lado ->), sobre a verdadeira necessidade deste assunto em meu cotidiano, assunto este que nasceu nos idos de 1975 (não lembro ao certo), por um engenheiro civil, sabe-se lá o nome.

Ponto. Isso já mostra a ingrime curva de meu conceito quanto à aplicabilidade dos patterns: afirmo que TODO analista de sistema (que se preze) deve conhecê-los e saber aplicá-los.

Resumindo, para não estender o post, podemos dividi-los em 3 grupos: Criacionais (que trata de melhores mecanismos de instancias das classes), Estruturais (que trata da interação entre os componentes, fazendo com que trabalhem em conjunto, cada qual com suas atribuições, solucionando melhor as requisições) e Comportamentais (trata da comunicação dos componentes, trazendo mais dinamicidade na resposta da requisição). Enfim, cada qual com suas consagradas técnicas.

Citando algumas “técnicas”, ou melhor dizendo: Padrões, podemos iniciar com os criacionais factoryMethod (um componente que simula uma fabrica de classes, organizadas numa idéia de “switch”,  ligado a uma interface que determina todas as subclasses),  singleton (trazendo toda uma economia de instâncias, entende-se “static” ou “static final”) e abstract factory (um componente “singleton”, que não trata apenas um switch de classes, mas também as famílias destas classes), passando pelos estruturais decorator (extendendo um componente concreto e um abstrato, decorando classes de forma independentes), bridge (fazendo uma ponte do componente abstrato com uma interface de ações), facade (“feaçaid”, liga-se a um componente concreto, economizando repetitivas chamadas de funções de diversas classes) , flyweight (que pra mim é a junção da idéia do factory com brigde, genial, economia grande memória) e adapter (um tanto quanto confuso, mas tornando “maleável” interfaces obsoletas ligando-se a um componente adaptador que possa incrementar novas ações, existentes nas suas subclasses), indo parar nos comportamentais memento (ideia genial de “backup” de objetos), iterator (largamente utilizado no Java, agrupamento e busca de classes/objetos) e chains of responsability (provendo um escudo abstrato entre o cliente e o pacote de classes, através de uma requisição é possível buscar a classe correta, e não encontrando chama-se um “sucessor”, que por sua vez é um auto-relacionamento).

Bom, existem muito mais, cheguei a contar 25 padrões em algum livro.

Concluindo: O segredo é saber o propósito de cada um, e a solução que cada um provê ao seu negócio, enxugando o mundo de classes soltas, fazendo um encadeamento mais inteligente entre elas.

Até a próxima! \m/