A maior rede de estudos do Brasil

Grátis
45 pág.
Apostila de Modelagem Orientada a Objetos com UML

Pré-visualização | Página 11 de 13

desenvolvimento de um soft ware.
De acordo com Christopher Alexander (1977 apud 
GAMMA et al., 2000), “cada padrão descreve um 
problema no nosso ambiente e o núcleo da sua solução, 
de tal forma que você possa usar esta solução mais de um 
milhão de vezes, sem nunca fazê-lo da mesma maneira”.
O autor Christopher Alexander é o precursor dos 
trabalhos relacionados a padrões (patt erns). Ele é um 
arquiteto e matemáti co que fi cou muito conhecido, 
na década de 1970, pelos trabalhos desenvolvidos na 
criação de padrões geométricos e matemáti cos na área 
de arquitetura.
Na década de 1990, quatro autores - Erich Gamma, 
Richard Helm, Ralph Johnson e John Vlissides -, lançaram 
o primeiro catálogo de padrões de projeto, chamado livro 
GoF (Gang of Four). Desde então o desenvolvimento de 
projetos de soft ware fundamenta-se em terminologia e 
soluções baseadas nesse catálogo. 
Para Gamma et al. (2000), padrões de projetos são 
descrições de objetos e classes comunicantes que são 
customizados para resolver um problema geral de projeto 
num contexto parti cular. Segundo os autores, um padrão 
tem quatro elementos essenciais:
• Nome do padrão: é uma referência que identi fi cará o 
problema de projeto, suas soluções e consequências.
• Problema: descreve o problema e o contexto com o 
intuito de saber quando aplicar o padrão.
• Solução: descreve os elementos que compõem o 
projeto, seus relacionamentos, suas responsabilidades e 
colaborações.
• Consequências: são os resultados e a análise das 
vantagens e desvantagens (trade-off s) da aplicação padrão.
Existem outros catálogos de padrões, tais como 
Padrões JEE, Padrões Microsoft , Padrões SOA etc. Eles são 
referências em seus respecti vos campos de atuação.
Os padrões de projeto são representados por 
gráfi cos. Os objetos e classes são desenhados, e os seus 
relacionamentos, apresentados. Após essa notação 
gráfi ca, os códigos são especifi cados e explicados. 
Além dessa notação gráfi ca, é necessária uma descrição 
dos padrões de projeto. Nela são especifi cadas decisões, 
análise de custo-benefí cio, exemplos etc. Gamma et al. 
(2000) descrevem uma estrutura uniforme para essas 
informações:
• Nome e classifi cação do padrão: nome do padrão e 
indicação da categoria dele.
• Intenção e objeti vos: curta declaração das intenções e 
objeti vos do padrão.
• Também conhecido como: outros nomes também 
uti lizados para o padrão, se existi rem.
• Moti vação: cenário do problema e da solução de projeto 
por meio do padrão.
• Aplicabilidade: situações de aplicação do padrão de 
projeto.
• Estrutura: representação gráfi ca das classes do padrão. 
Podem-se uti lizar diagramas de interação.
• Parti cipantes: classes e objetos que parti cipam do 
padrão de projeto e suas responsabilidades.
• Colaborações: como os parti cipantes colaboram para 
executar suas responsabilidades.
• Consequências: indicação das consequências da 
aplicação do padrão, como custo-benefí cio.
• Implementação: informações relati vas à implementação 
do padrão de projeto, como linguagem de programação, 
dentre outras.
Modelagem orientada a objetos com UML
36
• Exemplo de código: fragmentos ou blocos de códigos da 
implementação do padrão.
• Usos conhecidos: exemplos do padrão encontrados em 
sistema reais.
• Padrões relacionados: descrição dos padrões 
relacionados ao padrão uti lizado.
Figura 35. Tirinha de humor sobre design patterns. Fonte: http://
vidadeprogramador.com.br/2011/07/08/design-patterns/.
1.2. Catálogo dos padrões de projeto GoF
O catálogo de padrões GoF está dividido em três 
categorias: criação, estrutural e comportamental. Os 
padrões de criação são uti lizados para criar objetos. Os 
padrões estruturais preocupam-se com a composição 
de objetos e classes. Já os padrões comportamentais 
lidam com a interação de objetos e classes e suas 
responsabilidades.
Além dessas categorias, Gamma et al. (2000), 
organizam o catálogo GoF em 23 padrões, conforme 
relação, em ordem alfabéti ca, descrita a seguir.
1. Abstract factory: fornece uma interface para a criação 
de famílias de objetos relacionados ou dependentes sem 
especifi car suas classes concretas.
2. Adapter: converte a interface de uma classe em outra 
esperada pelos clientes. O adapter permite que certas 
classes trabalhem em conjunto, pois, de outra forma, seria 
impossível, por causa de sua interfaces incompatí veis.
3. Bridge: separa uma abstração da sua implementação, 
de modo que as duas possam variar independentemente.
4. Builder: separa a construção de um objeto complexo 
da sua representação, de modo que o mesmo processo de 
construção possa criar diferentes representações.
5. Chain of responsibility: evita o acoplamento do 
remetente de uma solicitação ao seu desti natário, dando a 
mais de um objeto a chance de tratar a solicitação. Encadeia 
os objetos receptores e passa a solicitação ao longo da 
cadeia até que um deles a trate.
6. Command: encapsula uma solicitação como um objeto, 
permiti ndo que se parametrize clientes com diferentes 
solicitações, se enfi leire ou registre (log) solicitações e se 
suporte operações que podem ser desfeitas.
7. Composite: compõe objetos em estrutura de árvore 
para representar hierarquias do ti po partes-todo. O 
composite permite que os clientes tratem objetos individuais 
e composições de objetos de maneira uniforme.
8. Decorator: atribui responsabilidades adicionais a 
um objeto dinamicamente. Os decorators fornecem 
uma alternati va fl exível a subclasses para extensão da 
funcionalidade.
9. Facade: fornece uma interface unifi cada para um 
conjunto de interfaces em um subsistema. O façade defi ne 
uma interface de nível mais alto que torna o subsistema 
mais fácil de usar.
10. Factory method: defi ne uma interface para criar um 
objeto, mas deixa as subclasses decidirem qual classe a 
ser instanciada. O factory method permite a uma classe 
postergar (defer) a instanciação às subclasses.
11. Flyweight: usa comparti lhamento para suportar 
grandes quanti dades de objetos, de granularidade fi na, de 
maneira efi ciente.
12. Interpreter: dada uma linguagem, defi ne uma 
representação para sua gramáti ca juntamente com um 
interpretador que usa a representação para interpretar 
sentenças nesta linguagem.
13. Iterator: fornece uma maneira de acessar 
sequencialmente os elementos de um objeto agregado sem 
expor sua representação subjacente.
14. Mediator: defi ne um objeto que encapsula a forma 
como um conjunto de objetos interage. O mediator 
promove o acoplamento fraco ao evitar que os objetos se 
refi ram explicitamente uns aos outros, permiti ndo que você 
varie suas interações independentemente.
15. Memento: sem violar a encapsulação, captura e 
externaliza um estado interno de um objeto, de modo que 
o mesmo possa, posteriormente, ser restaurado para esse 
estado.
16. Observer: defi ne uma dependência um-para-muitos 
entre objetos, de modo que, quando um objeto muda de 
estado, todos os seus dependentes são automati camente 
noti fi cados e atualizados.
17. Prototype: especifi ca os ti pos de objetos a serem 
criados usando uma instância prototí pica e cria novos 
objetos copiando este protóti po.
18. Proxy: fornece um objeto representante (surrogate), ou 
um marcador de outro objeto, para controlar o acesso ao 
mesmo.
Modelagem orientada a objetos com UML
37
19. Singleton: garante que uma classe tenha somente uma instância e fornece um ponto global de acesso para ela.
20. State: permite que um objeto altere seu comportamento quando seu estado interno muda. O objeto parecerá ter mudado 
sua classe.
21. Strategy: defi ne uma família de algoritmos, encapsula cada um deles e torna-os intercambiáveis. O strategy permite que o 
algoritmo varie independentemente dos clientes que o uti lizam.