Padrões de Projeto (ou Design Patterns): o que são, para que servem e qual sua implicação de uso

16 de março de 2009, em Passos Iniciais, por Tárcio Zemel

Exemplo de Diagrama Entidade-Relacionamento (DER).

Quem já programa com linguagens OO (orientação a objetos) certamente trabalha ou, pelo menos, já ouviu falar, dos Padrões de Projeto ou Design Patterns. Os mais “vivenciados” na arte de programar já devem, inclusive, ter implementado um Padrão de Projeto em algum sistema ou software.

Mas nem todos conhecem os Padrões de Projeto e alguns sequer ouviram falar a respeito; por isso, neste artigo, falo um pouco a respeito dos Design Patterns. Para entender melhor o assunto, é preciso ter, pelo menos, noções de programação orientada a objetos – dê uma lidinha em nossa página Pré-requisitos para saber se você está apto a continuar a leitura.

O que são Padrões de projeto ou Design Patterns?

Primeiramente, vamos ler um trecho da definição de Padrões de Projeto da Wikipédia, onde consta que os Padrões de Projeto

descrevem soluções para problemas recorrentes no desenvolvimento de sistemas de software orientados a objetos. Um padrão de projeto estabelece um nome e define o problema, a solução, quando aplicar esta solução e suas conseqüências.

Excelente esta definição da Wikipédia. Para entender melhor, ainda, vamos pegar a definição mais objetiva de José Carlos Macoratti, que, em seu site, no artigo sobre o padrão MVC, define:

Padrões de projetos são soluções para problemas que alguém um dia teve e resolveu aplicando um modelo que foi documentado e que você pode adaptar integralmente ou de acordo com necessidade de sua solução.

Por exemplo, você está programando seu revolucionário sistema e percebe que será necessário ter acesso à uma instância de uma classe qualquer, e que esse acesso deve ser fácil e possível de ser feito em qualquer parte/página de seus códigos. Ao invés de você quebrar a cabeça e pensar em como fazer isso, utilize uma solução pronta! A solução para isso já existe – porque é uma situação muito comum em desenvolvimento de programas e se tornou um padrão de projeto – e seu nome é Singleton!

Quer dizer, corroborando ainda mais com a filosofia do “Não reinvente a roda!” – já comentada no artigo sobre frameworks -, os Padrões de Projeto existem para agilizar o desenvolvimento de aplicações e permitem que você “economize neurônios”, pois são soluções mais ou menos prontas para os problemas mais ou menos comuns do cotidiano de um programador.

E não se engane, pensado que padrões de projetos são “coisa de PHP”! Os design patters são soluções para problemas de software e, pense bem, uma solução para problemas genéricos não pode ficar restrita a uma linguagem específica. Portanto, conhecendo a solução que se quer, esta pode e deve ser aplicada não somente em PHP, mas em Java, Ruby, C#, .NET, e qualquer outra que você queira.

Para que servem os Padrões de Projeto?

Você já deve ter percebido que os Design Patterns servem para mostrar (ou demonstrar) soluções prontas para problemas que são comuns; soluções estas que podem ser implementadas em qualquer linguagem de programação.

O importante dos Padrões de Projeto são as definições dos problemas e a “melhor saída” para cada um deles. Através da análise de caso e de solução de uma situação, conhecendo os padrões de projeto você pode decidir qual usar, como usar e porque usar um padrão de projeto – se realmente for conveniente para o caso em foco.

Os padrões de projeto podem ser divididos por sua função ou escopo, sendo apresentados em 3 categorias principais, quais sejam, Padrões de Criação, Padrões Estruturais e Padrões comportamentais. Cada uma destas “categorias de padrões de projeto” contém os design patterns que são úteis a cada escopo.

Por exemplo, o padrão Singleton – que tem por objetivo garantir a existência de apenas uma instância de uma classe, mantendo um ponto global de acesso ao seu objeto – pertence à categoria de Padrões de Criação; o Adapter – que permite que classes com interfaces incompatíveis possam interagir entre si – pertence a Padrões Estruturais; e assim por diante. Confira uma boa listagem de padrões de projeto por categoria na Wikipédia.

Dando uma olhadinha no código fonte e pesquisando rapidamente em alguns tópicos dos fóruns oficiais do CodeIgniter, é possível observar que, dentre outros, alguns dos design patterns que o CodeIgniter implementa são:

Se alguém identificou mais algum padrão de projeto, basta comentar no artigo e eu complemento a listagem dos design patterns que o CodeIgniter implementa.

Na prática – e falando genericamente – não faz muita diferença para quem utiliza o CodeIgniter saber quais design patterns o framework usa nem exatamente como cada um deles funciona. Entretanto, saber disso auxilia você a “montar a tela mental” do “todo” e ter uma noção de como a “mágica” do CodeIgniter funciona!

Assine o feed CodeIgniter Brasil para não perder os próximos “truques”!  ;-)

9 comentários em "Padrões de Projeto (ou Design Patterns): o que são, para que servem e qual sua implicação de uso"

gravatar

Yuri Wayne Ferreira  em 16 de março de 2009

Show, já virei frequentador assíduo daqui. Espero cada vez mais matérias sobre o CI. Valeu!

gravatar

Matheus  em 19 de março de 2009

Excelente texto!! Blog add em meus favoritos!!!

gravatar

Tárcio Zemel  em 2 de abril de 2009


@ Yuri Wayne Ferreira
@ Matheus

Obrigado! Agradecemos e contamos com a presença de vocês! Abraços! :-D

gravatar

Nei  em 14 de dezembro de 2009

Rapaz, já até implementei um gerenciador do meu tempo (Pomodairo) para poder focar nos estudos no CI aqui viu… indo pro próximo post…

gravatar

Aline  em 15 de janeiro de 2010

Bem, ninguém citou nos coments quais design patterns podem ser identificados no CI, e vou tentar arriscar uns… =P

MVC (óbvio) – Models, Views e Controlers
Singleton – Config, Database…
Factory – Helpers
Adapter – Hooks (?)
Decorator – Views/Layouts/Default, Errors (?)
Strategy – hmmm… loading… pam! kkkkk

gravatar

Tárcio Zemel  em 20 de janeiro de 2010

@ Nei
Isso, aí, Nei! Vamos estudar o CodeIgniter para podermos desenvolver sistemas PHP excelentes!

@ Aline
Obrigado por complementar a informação, Aline! Creio que o entendimento ficou melhor, agora! Abraços!

Comente!