Padrões de Projeto Estruturais

Slides:



Advertisements
Apresentações semelhantes
Soluções elegantes para problemas recorrentes
Advertisements

Padrão de Projeto Iterator
PADRÕES DE PROJETO..
Design Patterns Patrícia Mateus nº3343 Carla Guerreiro nº3157
Modelagem de Software Orientado a Objetos
Design Patterns Builder Pattern
Projeto de Sistemas de Software
Projeto de Sistemas de Software
Projeto de Sistemas de Software
1 Introdução aos padrões de projeto (GoF) Conceitos preliminares –Mecanismos de herança –Princípio de Substituição de Liskov –Acoplamento concreto x Acoplamento.
Padrões - introdução O que é um padrão?
Padrão de Construção Factory Method
Design Patterns Projeto de Sistemas de Software.
Fundamentos da Engenharia de Software
Visão crítica sobre padrões: Over Engineering
Módulo III Padrões GOF Professores
Projeto de Sistemas de Software
Padrões de Projeto Aplicações empresariais são complexas
Design Patterns e você. Jay Moretti Grupo de desenvolvedores Actionscripts do Brasil
Design Pattern (Padrões de Projeto)
Padrões de Projeto.
Introdução Padrões de Projeto
Padrão de Projeto Iterator Projeto de Sistemas de Software Thiago Pinheiro de Araújo.
Trabalho Final de Padrões de Projeto
Padrões de Design Toacy Cavalcante de Oliveira. 2 April 20, 2015 Problema.
Padrões de Projeto Abstract Factory.
Padrões de Projeto de Software Orientado a Objetos
Padrões de Projeto Alcides Calsavara
1 Padrões: Composite (p. 163) Objetivo: compor objetos em estruturas de árvores para representar relações de parte/todo. “Composite” permite tratar objetos.
1 Design Patterns Israel Rios. 2 Origens A idéia de padrões de projeto não teve origem na ciência da computação Christopher Alexander A Pattern Language:
Padrão Composite Definição
1 - Introdução a Padrões de Projeto
Padrões de Projetos Professora Lucélia. Conceitos É uma solução conhecida para um problema comum São técnicas que nos dão uma boa solução para determinados.
Padrões de Projetos Orientados a Objetos I Wolley W. Silva.
Padrões de Projeto. O que são?  Soluções provenientes de diversos projetos e utilizados por diversos programadores;  Documentados em catálogos como.
Padrões de Projeto de Criação Padrões de Projeto Orientados a Objetos Prof a. Danielle Martin Universidade de Mogi das Cruzes.
1 Padrões de Projeto de Software Orientado a Objetos Programação Orientada a Objetos Prof. Fabio Kon - IME/USP.
1 Introdução aos Padrões de Projetos Créditos: Prof. Fabio Kon - IME/USP Adaptações: Prof. Nécio de Lima Veras.
Introdução a Padrões de Projeto Padrões de Projeto Orientado a Objetos Profa. Danielle Martin Universidade de Mogi das Cruzes.
Programação Orienta a Objetos (SI) Análise e Projetos de Sistemas (LCC) 1 - Introdução a Padrões de Projeto Eduardo de Lucena Falcão.
Introdução a Padrões de Projeto Padrões de Projeto Orientado a Objetos Profa. Danielle Martin Universidade de Mogi das Cruzes.
Modelagem Orientada a Objetos com UML Cursos para a CTI - IME/USP Dairton Bassi, Hugo Corbucci e Mariana Bravo Departamento de Ciência.
EA976 – Engenharia de Software
COMPONENTE DE GERAÇÃO DE BOLETOS BANCÁRIOS EM DELPHI Aluno: Jonas Ricardo Viel Prof. Adilson Vahldick - Orientador.
Padrões de Projeto Composite Observer Strategy Factory Method Mediator Façade.
Classe Abstrata É uma classe que não pode ser instanciada; Freqüentemente aparece no topo de uma hierarquia de classes de programação orientada a objetos;
Introdução OO.
Princípios de Análise e Projeto de Sistemas com UML 2ª edição
POO - Introdução Prof. Eduardo Falcão.
UML – Modelação da arquitectura
Singleton Definição: Quando usar? Tipo de padrão? Como? estrutural.
PROGRAMAÇÃO ORIENTADA A OBJETO - JAVA
Java: Interfaces Alcides Calsavara.
Singleton e Template Method
Aula 9 – Padrão Decorator
Introdução à programação orientada por objetos
Elisabeth Suescún Leandra Mara da Silva
Programação Orientada a Objetos
4 CONCEITOS BÁSICOS EM POO
Análise e Projetos de Sistemas
Projeto estacionamento
Desenvolvimento em Camadas
BANCO DE DADOS I.
Padrões de Projeto Comportamentais
Padrões de Projeto Estruturais
Rosemary Silveira Filgueiras Melo
Prof. Eduardo Bezerra CEFET/RJ Bacharelado em Ciência da Computação Arquitetura e padrões de software Prof. Eduardo Bezerra
Padrões de Projeto.
Arquitetura e padrões de software
Programação de Computadores II
Transcrição da apresentação:

Padrões de Projeto Estruturais Padrões de Projeto Orientados a Objetos Profa. Danielle Martin Universidade de Mogi das Cruzes

Padrão de Projeto Descrição da essência de uma solução comum apropriada a um problema conhecido e recorrente. Define boas práticas de programação. Facilita o reuso, flexibilidade e simplicidade do software. Deve ser suficientemente abstrato para ser reutilizado em diferentes aplicações.

23 Padrões de projeto – Gang of Four (GoF) Padrões de Projeto: Soluções reutilizáveis de software orientado a objetos Gang of four: Erich Gamma Richard Helm Ralph Johnson John Vlissides Publicado em 1994. Referência no assunto de design patterns.

Classificação dos padrões GoF Criacionais De criação: Dizem respeito à criação de objetos. Estruturais De estrutura: Tratam da composição de classes e objetos. Comportamentais Do comportamento: Tratam da colaboração (interação e responsabilidade) entre classes e objetos.

Classificação dos padrões GoF Os padrões GoF classificados por categorias são: Criação Estrutura Comportamento Classe Factory Class Adapter Interpreter Template Method Objeto Abstract Factory Builder Prototype Singleton Object Adapter Bridge Composite Decorator Facade Flyweight Proxy Chain of Responsibility Command Iterator Mediator Memento Observer State Strategy Visitor

Classificação dos padrões GoF Os padrões GoF classificados por categorias são: Criação Estrutura Comportamento Classe Factory Class Adapter Interpreter Template Method Objeto Abstract Factory Builder Prototype Singleton Object Adapter Bridge Composite Decorator Facade Flyweight Proxy Chain of Responsibility Command Iterator Mediator Memento Observer State Strategy Visitor

PADRÃO ADAPTER

O problema Uma loja de vendas utiliza objetos Funcionario para controle do pagamento de seus empregados. Os métodos calcularSalarioAnual e calcularSalarioMensal são sobrescritos pelas classes Gerente, Vendedor e Administrativo, devido a diferenças nas regras de cálculo de cada tipo de funcionário.

O problema Recentemente, a loja adquiriu uma de suas concorrentes e, ainda que as duas lojas irão operar isoladamente como lojas independentes, a gerência solicitou que ambos os sistemas sejam integrados para que a consulta de salários dos funcionários possa trazer informações de funcionários das duas lojas.

O problema No entanto, ao examinar a modelagem do sistema da loja 2, o analista encontrou a seguinte estrutura de classes: A interface Empregado do sistema da Loja 2 disponbiliza um método consultarSalario que recebe o período de consulta como parâmetro (mensal, trimestral ou anual). Este método pode ser utilizado para realizar a consulta desejada pela gerência, mas seu formato é diferente do sistema atual.

O problema Como podemos utilizar essas novas classes para integrá-las na aplicação original? ?

A solução Podemos criar uma classe Adaptadora, que irá funcionar como um intermediário entre as duas interfaces, adaptando o formato dos métodos da interface Funcionario para os métodos da interface Empregado. Esta é a ideia do padrão Adapter, que permite que uma classe criada com um formato diferente ou externo ao sistema atual possa ser utilizada com as interfaces existentes no mesmo, quase como um adaptador de tomadas do mundo real:

A solução Dessa forma, a nova modelagem do sistema ficaria assim:

A solução

A solução

Diferença entre Class Adapter e Object Adapter Utiliza herança para relacionar o adaptador com o adaptado. Solução mais rígida, pois Java e C# não suportam herança múltipla. Object Adapter Utiliza composição para relacionar o adaptador com o adaptado. Solução mais flexível.

PADRÃO BRIDGE

O problema Considere o seguinte diagrama das classes de um sistema bancário: Como podemos perceber, existe uma classe abstrata Conta que implementa alguns comportamentos concretos, como sacar, depositar e transferirParaConta. Existem também dois tipos de contas distintas, a ContaCorrente e a ContaPoupança, cada uma com suas particularidades: da conta corrente é cobrada uma tarifa mensal correspondente à uma cesta de serviços e a conta poupança permite a capitalização do dinheiro aplicado, sem nenhuma cobrança de tarifas.

O problema O que acontece, no entanto, quando o banco em questão decide criar um novo tipo de conta? Surge assim a ContaMista, uma conta corrente, com sua devida cesta de serviços, mas que também permite a capitalização. Como isso afetaria as classes do nosso sistema?

Solução 1? Como já temos uma abstração Conta, basta criar uma nova classe concreta ContaMista, com os comportamentos aplicáveis: Apesar de parecer a solução mais simples à primeira vista, reparem que a operação cobrarTarifa é implementada duas vezes, duplicada entre a a ContaCorrente e a ContaMista, e a operação capitalizar também está duplicada, entre a ContaPoupanca e a ContaMista.

Solução 2? Vamos tentar criar novas abstrações que também estendam o comportamento de Conta:

Uma classe pode ter apenas uma superclasse. Solução 2? Quase lá! Mas o Java e outras linguagens não aceitam herança múltipla, como aparece no caso da ContaMista. Uma classe pode ter apenas uma superclasse. Mas se a ContaMista é uma ContaComTarifa e é também uma ContaComCapitalização, e não pode herdar ambas, como vamos resolver esse problema?

A solução – Padrão Bridge Percebemos que há dois comportamentos distintos que se combinam de maneiras diferentes entre os vários tipos de conta. Vamos então usar nossos conhecimentos sobre abstrações de interfaces para isolar esses comportamentos em classes distintas e usar a composição para criar uma “ponte" entre a classe Conta e esses comportamentos. A ideia do Padrão Bridge é desacoplar duas ou mais hierarquias de comportamentos em abstrações diferentes e usar a composição para relacioná-las.

A solução – Padrão Bridge Com essa implementação, podemos inclusive implementar novos tipos de tarifas e de capitalização no futuro, sem prejudicar nossa estrutura. Exemplo:

Classe Conta

Classes filhas

Classe principal

PADRÃO COMPOSITE

O problema Componentes de hardware podem ser combinados para formar uma peça de hardware, que por sua vez também é um componente e pode ser usado para compor um computador customizado.

Anti-padrão Cada composição de componente é modelada individualmente. A solução é complexa e pouco flexível.

Anti-padrão Código da classe Computador

A solução: padrão Composite O padrão Composite propõe a composição recursiva para compor objetos de mesmo tipo, a fim de criar objetos compostos em uma estrutura tipo a de árvore.

A solução: padrão Composite Todos os componentes herdam de uma superclasse comum. Componentes compostos (como computador, placa mãe e placa de vídeo) podem ser compostos por outros componentes.

Classes Componente e ComponenteComposite

Classes HardDisk e Computador Objeto folha Objeto composite

Aplicacao cliente