Design Patterns

Fala, galera, peço desculpa pela demora em postar algum artigo novo, na verdade eu andei trabalhando em alguns, mas sabe como é tá difícil acabar esses artigos, trabalhando demais. Então resolvi falar em um artigo que foi trazido por um amigo, o Ivo Nascimento, que mantém o podcast php5minutes (que você acompanha aqui ou pelo site dele http://www.ianntech.com.br), padrões de projeto.

Mas o que são padrões de Projeto? Nada mais que soluções padrões para problemas recorrentes. Então vem a pergunta pro Tio. “Mas então tudo o que eu faço que solucione um problema é um padrão!” E o tio responde Não! Saca só um padrão de projeto tem que seguir algumas regras:

1. Abstração: Um padrão de projeto tem que resolver o mesmo problema em casos diferentes, exemplo você tem de validar todos os seus campos de formulário e você cria um único padrão chamado VALIDADOR, olha como eu sou criativo, para validar diferentes entradas. Esse padrão tem de servir para a grande maioria, se não para todos os tipos de dados que vão entrar no seu formulário.
2. Solução não complicante: Isso quer dizer que o seu padrão não pode complicar mais o seu código sendo aplicado do que seria a solução com a sua linguagem nativa. No exemplo acima, de nada adiantaria criar um padrão VALIDADOR que tivesse metodos que fossem funções nativas do PHP. Tipo $validador->is_int($input). Isso não é um padrão é uma piazisse, ou sobrinhada.
3. Iteratividade com outros padrões: Isso quer dizer que seu padrão deve poder usar outros padrões e outros padrões devem poder usá-los, no caso acima eu vou citar o exemplo, mas vou desenvolvê-lo mais a frente em outro artigo, no nosso VALIDADOR vamos usar factory para determinar os tipos de dados e singleton para garantir que teremos um unico objeto validador por campo de formulário.

Pois bem, no dia a dia usaremos Padrões de Projeto, na verdade usamos, para diminuir nosso trabalho, quando você tem que refazer uma tarefa, tipo escrever um crud, um sistema de ACL etc. um padrão de projeto sempre será bem vindo. Para isso devemos sempre ter em mente que é necessário documentar os mesmos, tanto no código para entender a mecânica como na base de conhecimento da empresa, ou sua mesmo, descrevendo o que aquele padrão faz e aonde está a documentação de código dele.

Um exemplo clássico que eu uso de padrão de projeto que eu uso é a minha classe de envio de SMS, que foi escrita uma vez, utilizamos em N Projetos, e que me economiza um bom tempo de codificação.

Bem esse artigo é uma visão simplista de o que é um DP (Design Patterns) eu e os outros colunistas do Blog vamos tentar destrinchar alguns DPs aqui para melhorar o entendimento geral, na verdade segunda mesmo já terei postado um artigo sobre FACTORY, por isso continue acomponhando a gente no Twitter e aqui no blog

No related posts.