Tags: , , | Categories: Padrões de Projeto Posted by Rafael on 19/10/2010 06:12 | Comentários (4)

Com esse post, inicio uma série sobre Padrões de Projeto (Design Patterns). Abordarei os 23 padrões de projeto de uma forma bem simples. A minha intenção é fazer uma breve descrição sobre cada padrão, seguindo de alguns exemplos, para ajudar àqueles que desenvolvem aplicativos Orientado a Objetos e não conhecem Padrões de Projeto.

Como citei em um post anterior, Padrões de Projeto devem ser utilizados com ponderação. Cada padrão foi criado para solucionar problemas específicos do dia-a-dia de desenvolvedores, porém, como todo e qualquer padrão, a grande maioria requer maior codificação. Por isso, a sua utilização em demasia, é prejudicial. Podemos chegar ao ponto de querer matar um simples e inofensível inseto com uma bazuca. Totalmente sem sentido.

Portanto, bom senso é muito bem-vindo na utilização de Padrões de Projeto.

Quando usamos padrões, agregamos qualidade ao nosso desenvolvimento. Consequentemente, diminuímos a produtividade. É impossível aumentar a qualidade e a produtividade ao mesmo tempo, de qualquer que seja o produto (no nosso caso, software). O que devemos fazer, é encontrar um ponto ótimo entre qualidade e produtividade, mas isso é assunto pra um outro post, só sobre Qualidade x Produtividade, o que não é o nosso foco agora.

Muitas vezes utilizamos técnicas para resolver problemas e criar soluções no nosso dia-a-dia, e nem sabemos que essas técnicas são padrões de projeto. Isso já aconteceu comigo, principalmente quando comecei a estudar padrões de projeto. Portanto, não se espante se ao longo do nosso estudo, se deparar com um padrão que você já utiliza, mas não sabia que é um padrão de projeto.

Os Padrões de Projeto são classificados em 3 grupos, de acordo com suas finalidades: Padrões de Criação, Padrões Estruturais e Padrões Comportamentais. São eles:

Padrões de Criação:

Padrões Estruturais:

  • Adapter
  • Bridge
  • Composite
  • Decorator
  • Façade
  • Flyweight
  • Proxy

Padrões Comportamentais:

  • Chain of Responsability
  • Command
  • Interpreter
  • Iterator
  • Mediator
  • Memento
  • Observer
  • State
  • Strategy
  • Template Method
  • Visitor

Iniciarei pelos seguintes padrões, que são os mais simples e comuns:

Logo após, darei sequência aos demais padrões.

Espero que gostem.

Aguardem!

Comentários

Frederico Brazil on 23/10/2010 00:24 Fala Rafael!



Cara, não concordo muito com sua afirmação a seguir: "Quando usamos padrões, agregamos qualidade ao nosso desenvolvimento. Consequentemente, diminuímos a produtividade. É impossível aumentar a qualidade e a produtividade ao mesmo tempo, de qualquer que seja o produto (no nosso caso, software)."



Os padrões quando são seguidos geram boas práticas, e quando uma pessoa tem prática em realizar uma atividade, só pode fazer essa atividade mais rápido. Quando toda a equipe domina padrões, todas desenvolveram mais rápido porque não precisarão reinventar a roda.



Acredito que a afirmação mais correta seria "...Consequentemente aumentamos o preço", porque não existem desenvolvedor junior que conheça padrões de verdade, e uma equipe só de Sêniors com certeza será mais cara que uma equipe de Plenos/Juniors que se sentem Sêniors.



Abraços

Rafael Brazil on 23/10/2010 02:26 Fala Fred,



Entendo e concordo com o seu ponto de vista. Realmente, quando temos uma equipe sênior, na maioria das vezes, não temos esse problema. Pressupõe-se que a equipe domine Padrões de Projeto, já que se trata de uma equipe de seniores.



Mas, na prática, sabemos que não é bem assim que funciona.



É insustentável manter uma equipe apenas de analistas seniores, pois, como você mesmo disse, é muito cara. Na grande maioria das equipes de desenvolvimento, há analistas juniores, plenos e seniores. Nenhuma empresa, em são consciência, manteria uma equipe apenas de seniores para realizar todos os projetos de desenvolvimento.

Imaginemos que uma empresa decida adotar a utilização de Padrões de Projeto para um determinado projeto. Temos que levar em consideração o fator da resistência pessoal dos membros da equipe. Nem todos analistas juniores e plenos têm experiência em desenvolvimento utilizando Padrões de Projeto, e eles são partes importantíssimas para o sucesso do projeto.



Mas, essa é apenas uma perspectiva do problema. Apenas um ponto de vista dos diversos que existem sobre esse assunto.



Abraços!
Frederico Brazil on 24/10/2010 07:38 É normal que as equipes não sejam apenas de Seniores, mas quando são definidos o uso de padrões, essas definições partem de Seniores ou maiores.

Os plenos e juniores devem ser ensinados a utilizarem os padrões, e para que eles servem, um analisa Senior ou um Arquiteto, caso haja, também tem a responsabilidade de fazer a equipe amadurecer.

Já ouvi casos onde uma equipe de estagiários implementava todos os padrões necessários no sistema, porque era muito bem auxiliados pelo Arquiteto da empresa.

Abs

Rafael Brazil on 07/01/2011 18:59 Sim, concordo com todos os pontos do seu argumento.

Mas, mesmo assim, quero enfatizar que na maioria das empresas não é bem assim que a coisa funciona. A não ser que o negócio da empresa seja TI, como a Microsoft por exemplo, raramente os líderes da empresa têm essa visão. São raríssimas as empresas que têm essa visão e praticam a TI como ela realmente deve ser praticada.

No momento, vamos dar foco ao técnico, aprender Padrões de Projeto para galgarmos melhores empregos, que façam jus ao nosso know-how, como um líder técnico ou até mesmo um arquiteto ou engenheiro de software.

Abraços.
Os comentários estão fechados