Padrões de projeto: parte 1 de 3

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 loja!) irei iniciar algumas séries de artigos com 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

gof022

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

gof031

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

gof04

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.

gof05

Singleton

· Garante que uma classe tem apenas uma instância, e proporciona um ponto de acesso global a ela

· Use Singleton quando:

o Deve haver exatamente uma instância de uma classe, e ela deve ser acessível aos clientes a partir de um ponto-de-acesso conhecido

gof06


»crosslinked«

nandopedrosa

Analista de Finanças e Controle - Ministério da Fazenda/Coordenação de Sistemas Graduação: Universidade Federal de Pernambuco Certificações: ITIL Foundation Certified Java Programmer Certified Java Associate Certified Aprovações: Concurso Ano Cargo Posição Organizadora PBGÁS 2007 Analista de Sistemas 1 FCC SERPRO 2008 Administração de TI 1 CESPE COPERGÁS 2008 Analista de Sistemas 1 UPENET INMETRO 2007 Analista de Sistemas 2 CESPE STN 2008 AFC-TI 2 ESAF STJ 2008 Analista Judiciário 3 CESPE TRF-5 2008 Analista Judiciário 5 FCC TRF-5 2008 Técnico Judiciário 5 FCC TCU 2008 ACE-TI 7 CESPE TJ-PE 2007 Analista Judiciário 11 FCC BNDES 2008 Analista de Sistemas 27 CESGRANRIO

Você pode gostar...

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *