uma descricao ou modelo (de como resolver um problema) que pode ser usado em muitas situacoes diferentes.Design patterns podem acelerar o processo de desenvolvimento, oferecendo paradigmas de desenvolvimento testados e provados. Um projeto de software eficaz deve prever questoes para que nao haja problemas na implementacao. O reuso dos design patterns ajuda a prevenir problemas maiores, alem de melhorar a legibilidade do codigo para os programadores e arquitetos familiares com os patterns.As pessoas frequentemente sabem aplicar somente algumas tecnicas de projeto de software para sanar certos problemas. Estas tecnicas sao dificeis de aplicar a uma gama mais ampla de problemas. Design patterns oferecem solucoes gerais, documentadas em um formato que nao requer especificidades ligadas a um problema particular.Alem disso, os patterns permitem aos desenvolvedores se comunicarem utilizando nomes conhecidos nas interacoes de software. Podem-se melhorar os design pattterns ao longo do tempo, os tornando mais robustos que designs ad-hoc (significado: para resolver determinado problema ou realizar uma tarefa especifica).Creational Design Patterns: dizem respeito a instanciacao de classes. Podem ser divididos em patterns de criacao de classes e patterns de criacao de objetos. Enquanto os patterns de criacao de classes utilizam heranca no processo de instanciacao, os patterns de criacao de objetos utilizam delegacao. Nomes dos design patterns criacionais (que serao explicados em outros posts): Abstract Factory, Builder, Factory Method, Object Pool, Prototype, Singleton.Structural design patterns: dizem respeito a composicao da classe e do objeto. Os patterns estruturais de classes utilizam heranca para compor interfaces. Os patterns estruturais de objetos definem formas de compor objetos a fim de obter uma nova funcionalidade. Nomes dos design patterns estruturais (que serao explicados em outros posts): Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Private Class Data, Proxy.Behavioral design patterns: dizem respeito a comunicacao dos objetos da classe. Nomes dos design patterns estruturais (que serao explicados em outros posts): Chain of responsibility, Command, Interpreter, Iterator, Mediator, Memento, Null Object, Observer, State, Strategy, Template method, Visitor.Criticas:O conceito de design patterns tem sido criticado por algumas correntes da ciencia da computacao.a) Aponta o problema errado: a necessidade de padroes resultam do uso de linguagens de computador ou tecnicas com habilidade de abstracao ineficiente. Num projeto ideal, um conceito nao deve ser copiado, mas meramente referenciado. Mas se algo e referenciado em vez de copiado, nao ha padrao para rotular e catalogar. Paul Graham assim escreve em Revenge of the Nerds.Peter Norvig tambem tem um argumento similar. Ele demonstra que 16 em 23 patterns no livro Design Patterns (que e primariamente focado em C++) sao simplificados ou eliminados (atraves do suporte direto da linguagem) em Lisp ou Dylan.Carece de fundamentos formais: o estudo dos design patterns tem sido excessivamente ad hoc, e alguns argumentam que o conceito necessita ter um posicionamento mais formal. Na OOPSLA 1999, a Gang of Four foi submetida a um "julgamento", em que foi "condenada" por 23 dos "jurados" que participaram do "julgamento" por "crimes contra a ciencia da computacao".Leva a solucoes ineficientes: a ideia do design pattern e uma tentativa de padronizar o que ja e considerado melhor pratica. Em principio isto pode parecer benefico, mas