RSS Feed
Nov 10

Dicas sobre Padrões de Projetos

Posted on Monday, November 10, 2008 in TI

Dúvida de um aluno:

- Prof. Kelon, gostaria que você pudesse nos sugerir o uso de alguns padrões para utilizarmos no nosso mini-projeto. Conheço os padrões de criação Factory e Singleton. Além da própria arquitetura MVC, outros padrões que já utilizei foram o Façade e o DAO. Além destes, o senhor sugere mais algum padrão que podemos utilizar? Peço que nos passe também algum link que porventura você tenha utilizado.

A minha resposta segue logo abaixo.

Três coisas:

  1. Para poder recomendar algo, preciso conhecer melhor como você está projetando seu software e para qual ambiente;
  2. Padrões de Projeto (PP) são usados por necessidade e não ‘usar por usar’. É a mesma coisa de você querer encaixar Herança onde não existe só para depois dizer que usou polimorfismo. Sei que não é estritamente seu caso, pois entendo o que você está pedindo, porém é salutar ressaltar;
  3. Padrões de Projeto não são solução para software mal projetado. Novamente, não estou sugerindo que este seja seu caso, mas talvez seja o caso de alertá-los para ‘Buzzword bingo‘ (vídeo de comercial IBM).

Retomando o que falei no início, elaborarei um pouco mais o item (3). Volto a falar, mais uma vez, que balas de prata não existem e possivelmente nunca existirão :-) O mais próximo que temos da famigerada bala de prata são bons projetistas (arquitetos) de software (de arquiteturas), pois eles buscam direta e primariamente minimizar os problemas essenciais de software, principalmente complexidade e conformidade (com o ambiente onde é implantado). Por isto que ratifiquei o link compartilhado e enviei outro sobre o mesmo assunto: Projeto de Software Orientado a Objetos.

De nada vale usar os 23 padrões de projeto clássicos se você força uma hierarquia de classes apenas para usar determinado padrão, isto é, você adapta seu projeto para acomodar um padrão. O que deveria ocorrer é muito diferente: o projeto de sua aplicação, naturalmente, sugerirá os padrões a serem aplicados.

Por exemplo, considere o caso de um objeto exigir mudanças em outros quando ele próprio é alterado, mas você não sabe quantos outros objetos necessitam ser modificados, como em um software de segurança residencial que dispara sinal de alerta para os vários alarmes no momento que a residência é invadida. Este problema é recorrente em várias outras situações e é resolvido com o padrão Observer. A depender de como sua solução foi projetada, o padrão Observer será a solução óbvia. Claro que ter conhecimento sobre PP auxilia a pensar e projetar as soluções, porém sozinhos não resolvem problema algum. O problema de projeto de software é mais embaixo, este é o ponto.

Para aprender a projetar software OO, recomendo Larman, C. 2004 Applying UML and Patterns: an Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition). Prentice Hall PTR. Livro que vai do básico ao avançado em se tratando de análise e projeto orientados a objetos.

Conheço os padrões de criação Factory e Singleton. Além da própria arquitetura MVC, outros padrões que já utilizei foram o Façade e o DAO. Além destes, o senhor sugere mais algum padrão que podemos utilizar? Peço que nos passe também algum link que porventura você tenha utilizado.

Você já usa vários padrões sem saber (pena o link não exibir alguns dos códigos).Mas, continuando a explicação anterior, padrões de projetos são usados quando se identifica uma oportunidade para tal, isto é, quando percebe-se que determinado problema é recorrente e já tem solução disponível. Quando isto ocorre, você consulta catálogos de padrões, verifica se há um padrão que resolve o problema e lê como ele deve ser solucionado. Para isto, sugiro ler Comentários finais sobre Design Patterns, que aponta para Sinopse dos Design Patterns da “Gang of Four”, pois é um resumo bem elaborado dos padrões clássicos de GoF.A [finada?] Argo Navis tem dois ótimos cursos no tema, com material disponível para download: J930: GoF Design Patterns em Java e J931: J2EE Design Patterns. A Argo Navis ainda disponibiliza um mini-curso sobre o tema. Veja o que há nos pré-requisitos do segundo curso: “[...] É fortemente recomendado que o aluno tenha conhecimentos de Design Patterns clássicos (GoF) – pelo menos os mais importantes (Observer, Composite, Strategy, Command, Factory Method, Abstract Factory, Iterator, Proxy, Adapter, Façade, Singleton, Decorator) pois eles não serão revisados e são aplicados em vários padrões J2EE. [...]” (Grifo meu). Sendo assim, a dica é ler os dois primeiros capítulos do livro Design Patterns: Elements of Reusable Object-Oriented Software, de Gamma e demais, e depois ler esses padrões citados. O primeiro capítulo do livro explica o que são padrões de projeto, enquanto que o segundo exemplifica seu uso no projeto de um editor de textos complexo.

O livro da GoF é leitura obrigatória para qualquer engenheiro de software comprometido com sua carreira. Subindo um pouco o nível de abstração, seguem Pattern-Oriented Software Architecture: a System of Patterns, de Buschmann e colegas, e Patterns of Enterprise Application Architecture, de Fowler. No nível mais abstrato, Software Architecture in Practice, 2nd edition, de Bass, Clements e  Kazman. Catálogos de PP online:

Comment (1) | Tags: ,