Introdução Padrões de Projeto Princípios de Design Pattern Prof. Wolley.
Transcript of Introdução Padrões de Projeto Princípios de Design Pattern Prof. Wolley.
Introdução Padrões de Projeto
Princípios de Design Pattern Prof. Wolley
Introdução Padrões de Projeto
• Um Design Pattern é uma técnica de modelagem de classes e objetos que resolve um problema comum a diversos tipos de aplicativos.
Padrões ArquiteturaisFamílias de Padrões
• Gang Of Four – GOF• 23 – Padrões– Criação – Estrutura– Comportamento
GOF – 23 Padrões de Projeto
Propósito
Escopo
Criação Estrutural Comportamental
Classe Factory Method Adapter InterpreterTemplate Method
Objeto Abstract FactoryBuilderPrototypeSingleton
AdapterBridgeCompositeFaçadeFlyweightProxy
Chain of ResposibilityCommandIteratorMediatorMementoObserverStrategyVisitor
• J2EE: – Business Delegate,– Composite Entity,– Composite View,– Data Access Object,– Fast Lane, – Reader,– Front Controller,– Intercepting Filter,– Model, view ,controller– Service Locator,– Session Façade,– Transfer Object,– Value List Handler, – View Helper
Padrões ArquiteturaisFamílias de Padrões
http://java.sun.com/blueprints/corej2eepatterns/Patterns/
Princípios de Design
1. Programe para uma interface, não para um implementação
2. Prefira a composição de objetos à herança de classe
3. Encapsular o que varia
1 º Princípios: Programe para uma interface (Superclasse), não para um implementação– Quando a herança é utilizada apropriadamente
todas as classes derivadas sobrescrevem os métodos da superclasse.
1 º Princípios: Programe para uma interface, não para um implementação
1 º Princípios: Programe para uma interface, não para um implementação
• Não declare variáveis como instâncias de classes concretas, mas para classes abstratas ou interfaces;
1 º Princípios: Programe para uma interface, não para um implementação
• As classes ClienteDAO, ProdutoDAO e EstoqueDAO dependem da implementação concreta PostgreSQL
• Dependência da Implementação
1 º Princípios: Programe para uma interface, não para um implementação
• Mudanças muitas, vezes necessárias, pode desencadear um efeito colateral em classes dependentes.
1 º Princípios: Programe para uma interface, não para um implementação
1 º Princípios: Programe para uma interface, não para um implementação
1 º Princípios: Programe para uma interface, não para um implementação
• A interface representa uma abstração do comportamento de uma ou mais classes.
• Classes dependendo da interface
1 º Princípios: Programe para uma interface, não para um implementação
1 º Princípios: Programe para uma interface, não para um implementação
Estrutura das coleções e mapas
2º Princípio: Prefira a composição de objetos à herança
• Vantagens da Herança– Herança é definida estaticamente em tempo de
compilação;– é simples de usar uma vez que é suportada pela
linguagem;– Torna mais fácil de modificar a implementação
que esta sendo reutilizada;
• Desvantagem– As super classes definem parte da representação
física das suas subclasses. Certos aspectos herdados podem não fazer sentido em determinadas contextos;
2º Princípio: Prefira a composição de objetos à herança
2º Princípio: Prefira a composição de objetos à herança
2º Princípio: Prefira a composição de objetos à herança
3º Princípio: Encapsular o que pode variar
3º Princípio: Encapsular o que pode variar
• Olhar para uma classe, enxergar sua responsabilidade, abstrair suas possíveis alterações e criar uma nova classe.
• Se a sua classe precisa ter mais de uma responsabilidade, divida-as e as associe.
3º Princípio : Encapsular o que pode variar