Padrões de projeto: parte 1 de 3

| by nandopedrosa |

Imprimir junho 27th, 2009 | Posted in Artigos | Tags:

Saudações, comunidade concurseira !

Aqui quem fala é o Fernando Pedrosa, o mais novo colaborador da comunidade. Além de comentar algumas provas (a primeira, TRT 2 região já está disponível na materiais que ajudarão vocês concurseiros na sua jornada rumo à aprovação.

Antes gostaria de me apresentar brevemente.

Sou formado em Ciência da Computação pela Universidade Federal de Pernambuco, e trabalhei 2 anos na inciativa privada local de Recife. Após esse período resolvi que precisava de uma maior qualidade de vida e comecei a estudar para concursos. Inicialmente foquei em concursos menores e obtive algumas aprovações que me motivaram bastante. Depois de alguns meses estudando passei a focar nos “peixes grandes”, o que acabou resultando na minha aprovação na Secretaria de Tesouro Nacional, como Analista de Finanças e Controle – TI , em Brasília, cargo que ocupo hoje. Para um histórico mais completo da minha trajetória, podem dar uma olhada no meu perfil aqui no blog.

Mas vamos ao que interessa.

Esta semana começo uma série sobre um assunto que costuma ser o calo de muitas pessoas, especialmente aquelas da área de infra-estrutura: padrões de projeto.

Dividirei os posts em três partes, começando com os padrões Criacionais, depois os Estruturais, para terminarmos com os Comportamentais.

Bons estudos !

O que são padrões de projeto?

No livro Design Patterns, Elements of Reusable Object-Oriented Software (mais conhecido como o Gang of Four – GOF – em alusão aos seus autores), padrões de projeto são definidos desta forma:

“Cada padrão descreve um problema que ocorre repetidamente em nosso ambiente, e então descreve a solução para aquele problema, de tal forma que você possa usá-la milhões de vezes depois, sem na verdade fazê-lo do mesmo jeito duas vezes.”

Apesar da frase meio enigmática, o fato é que padrões de projeto são soluções arquiteturais de software para resolver problemas comuns, que sempre aparecem, testadas e h0mologadas como eficazes, ou seja, elas de fato resolvem aquele problema específico.

Dito isto, vamos aos padrões Criacionais.

Abstract Factory

· Proporciona uma interface para criar famílias de objetos relacionados ou dependentes sem especificar suas classes concretas

· Use Abstract Factory quando:

o O sistema deve ser independente de como seus produtos são criados, compostos e representados

o O sistema deve ser configurado com uma de múltiplas famílias de produtos

o Uma família de objetos de produtos relacionados é projetada para ser usada junta, e você precisa assegurar essa restrição

o Você quer proporcionar uma biblioteca de classes de produtos, e você só quer revelar suas interfaces, não suas implementações

Builder

· Separa a construção de um objeto complexo da sua representação, de forma que o mesmo processo de construção possa criar diferentes tipos de representações

· Use o Builder quando:

o O algoritmo para criar um objeto complexo deva ser independente das partes que constituem o objeto e de como ele é montado

o O processo de construção deva permitir representações diferentes para o objeto que é construído

Factory Method

· Define uma interface para criar um objeto, mas deixa as subclasses decidirem qual classe instanciar. O Factory Method permite uma classe deferir a instanciação às subclasses

· Use Factory Method quando:

o Uma classe não pode antecipar a classe de objetos que ela deve criar

o Uma classe quer que suas subclasses especifiquem os objetos que ela cria

Prototype

· Especifica os tipos de objetos para criar usando uma instância prototípica, e cria novos objetos copiando esse protótipo

· Use o Prototype quando/em:

o As classes para serem instanciadas são especificadas em run-time, como por exemplo, por dynamic loading

o Sistemas que utilizam o padrão Abstract Factory para criação de objetos. Neste caso, a hierarquia de classes pode se tornar muito complexa e o padrão Prototype pode ser uma alternativa mais simples, por realizar a mesma tarefa com um número reduzido de classes;

o Sistemas que possuem componentes cujo estado inicial possui poucas variações e onde é conveniente disponibilizar um conjunto pré-estabelecido de protótipos que dão origem aos objetos que compõem o sistema.