O termo Design Patterns (padrões de projeto) foi criado originalmente pelo engenheiro Christopher Alexander para documentar as soluções de projeto comumente utilizados na construção civil. Mais tarde, o termo passou a ser utilizado na área de informática como forma de descrever soluções para problemas encontrados no projeto de software orientado a objetos.
Com o surgimento dos frameworks mais modernos como JBoss Seam, Spring, entre outros, muito se tem discutido a respeito da importância dos Design Patterns.
Na época em que o programador escrevia grande parte do código de controle das aplicações, padrões como Singleton, Façade, DAO, Chain of Responsability, Command, entre outros, eram frequentemente utilizados para criar os pontos de extensão da aplicação, por onde novas funcionalidades podiam ser criadas sem a necessidade de mudanças drásticas no código existente.
Como atualmente a maioria das aplicações é construída sobre um framework, muitos desses padrões já estão incorporados ao projeto por fazerem parte dos frameworks. Por isso, especialistas garantem que nós não precisamos mais utilizar muitos dos Design Patterns existentes.
De fato, se pensarmos em usar os design patterns para resolver os problemas do núcleo da nossa aplicação, realmente eles não precisam ser implementados diretamente pelo programador. Porém, vários Design Patterns vão muito além dessa forma de utilização e apresentam soluções valiosíssimas para questões particulares de cada projeto. Problemas como a necessidade de executar regras específicas com base num modelo de herança complexo ou no estado de um objeto podem ser facilmente resolvidos usando Design Patterns que, além de padronizar o código, oferece facilidades para extender/alterar o modelo futuramente. Alguns exemplos de padrões que atacam essa linha são Strategy, State, Bridge, Decorator, entre outros.
Portanto, mesmo construindo aplicações a partir dos frameworks mais modernos, o conhecimento sobre Design Patterns continua sendo de grande importância para quem trabalha com linguagens orientadas a objetos, como Java, C#, etc.
E mais importante do que saber como implementar um Design Pattern, é saber qual é o problema que você pode resolver com cada padrão. Eu já ouvi várias pessoas dizendo que não entendem os padrões ou que não sabem como fazer uso eficiente deles. Isso certamente acontece porque os problemas resolvidos pelos padrões não são conhecidos.
Para quem quer começar a estudar Design Patterns, a referência principal é o catálogo GoF no livro "Padrões de Projeto - Soluções Reutilizáveis de Software Orientado a Objetos", Gamma E. et al. Esse livro descreve 23 padrões que se aplicam aos mais diferentes problemas de orientação a objetos.
Mas se você for a favor de cursos, relembrando o post do nosso amigo Julio Viegas sobre livro ou curso, a Globalcode tem um minicurso gratuito de 3hs - Introdução a Design Patterns - cujo objetivo é introduzir o conceito de Design Patterns e falar sobre alguns dos padrões mais conhecidos. Uma outra opção, mais apronfundada, é o curso - Core Patterns - de 40hs que trata dos 23 design patterns do GoF e outros 10 do catálogo Java EE BluePrints, com uma abordagem bastante voltada para os problemas resolvidos pelos padrões.
Para quem está lendo esse post em tempo, dia 19 de agosto eu mesma irei ministrar o minicurso de design patterns na Globalcode. Para se inscrever nesse minicurso ou ver outras datas disponíveis acesse o site da Globalcode.
Uma outra fonte de informação é uma entrevista onde comento um pouco mais sobre o que são os Design Patterns e como identificar a necessidade de utilizá-los em nossos projetos.
Com o surgimento dos frameworks mais modernos como JBoss Seam, Spring, entre outros, muito se tem discutido a respeito da importância dos Design Patterns.
Na época em que o programador escrevia grande parte do código de controle das aplicações, padrões como Singleton, Façade, DAO, Chain of Responsability, Command, entre outros, eram frequentemente utilizados para criar os pontos de extensão da aplicação, por onde novas funcionalidades podiam ser criadas sem a necessidade de mudanças drásticas no código existente.
Como atualmente a maioria das aplicações é construída sobre um framework, muitos desses padrões já estão incorporados ao projeto por fazerem parte dos frameworks. Por isso, especialistas garantem que nós não precisamos mais utilizar muitos dos Design Patterns existentes.
De fato, se pensarmos em usar os design patterns para resolver os problemas do núcleo da nossa aplicação, realmente eles não precisam ser implementados diretamente pelo programador. Porém, vários Design Patterns vão muito além dessa forma de utilização e apresentam soluções valiosíssimas para questões particulares de cada projeto. Problemas como a necessidade de executar regras específicas com base num modelo de herança complexo ou no estado de um objeto podem ser facilmente resolvidos usando Design Patterns que, além de padronizar o código, oferece facilidades para extender/alterar o modelo futuramente. Alguns exemplos de padrões que atacam essa linha são Strategy, State, Bridge, Decorator, entre outros.
Portanto, mesmo construindo aplicações a partir dos frameworks mais modernos, o conhecimento sobre Design Patterns continua sendo de grande importância para quem trabalha com linguagens orientadas a objetos, como Java, C#, etc.
E mais importante do que saber como implementar um Design Pattern, é saber qual é o problema que você pode resolver com cada padrão. Eu já ouvi várias pessoas dizendo que não entendem os padrões ou que não sabem como fazer uso eficiente deles. Isso certamente acontece porque os problemas resolvidos pelos padrões não são conhecidos.
Para quem quer começar a estudar Design Patterns, a referência principal é o catálogo GoF no livro "Padrões de Projeto - Soluções Reutilizáveis de Software Orientado a Objetos", Gamma E. et al. Esse livro descreve 23 padrões que se aplicam aos mais diferentes problemas de orientação a objetos.
Mas se você for a favor de cursos, relembrando o post do nosso amigo Julio Viegas sobre livro ou curso, a Globalcode tem um minicurso gratuito de 3hs - Introdução a Design Patterns - cujo objetivo é introduzir o conceito de Design Patterns e falar sobre alguns dos padrões mais conhecidos. Uma outra opção, mais apronfundada, é o curso - Core Patterns - de 40hs que trata dos 23 design patterns do GoF e outros 10 do catálogo Java EE BluePrints, com uma abordagem bastante voltada para os problemas resolvidos pelos padrões.
Para quem está lendo esse post em tempo, dia 19 de agosto eu mesma irei ministrar o minicurso de design patterns na Globalcode. Para se inscrever nesse minicurso ou ver outras datas disponíveis acesse o site da Globalcode.
Uma outra fonte de informação é uma entrevista onde comento um pouco mais sobre o que são os Design Patterns e como identificar a necessidade de utilizá-los em nossos projetos.
Comentários
Quero aqui deixar um link que fala sobre algo já discutido nesse portal.
Compondo seu comportamento: herança, Chain of Responsibility e Interceptors
http://blog.caelum.com.br/2010/06/28/compondo-seu-comportamento-heranca-chain-of-responsibility-e-interceptors/
Nesse link foi observado se Singleton não seria o canditado ao patterns de controle.
Nesse outro link são demonstra exemplo em experiência ao Padrões de Projetos.
http://www.javabuilding.com/academy/patterns.html
Dizer que a industria já fornece os desing patterns que já são vinculados em seus frameworks em regra temos um modelo default mas na certa refatorações e transformações vão ocorrer a não ser que já seja algo em propriedade ou lincença para suporte de algum fornecedor.