padrões de projetos orientados a objetos i wolley w. silva

Padrões de Projetos Orientados a Objetos I

Wolley W. Silva

Ementa Resumida

• Aplicar os Princípios da Orientação a Objetos na Modelagem e Programação;

• Conhecer e Aplicar os Padrões de Projeto (GoF) de acordo com suas categorias:– Padrões de Criação– Padrões Estruturais– Padrões Comportamentais

Bibliografia Básica

Princípios de Design

1. Programe para uma interface, não para um implementação

2. Dar preferencia (favorecer) a composição de objetos à herança de classe

3. Encapsular o que pode mudar

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

2º Princípio: Prefira a composição de objetos à herança

• Erich Gamma. (GOF)– “Quando a herança é usada cuidadosamente

(apropriadamente), toas as classes derivadas compartilharão sua interface”.

• Quando métodos e/ou atributos herdados não são utilizador por sua classes filhas.

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 novas classes.

• Se a sua classe precisa ter mais de uma responsabilidade, divida-as e as associe.

3º Princípio : Encapsular o que pode variar

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.

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

Padrão Strategy

• Objetivo:– Encapsulamento de algoritmos que podem variar

com facilidade para prover um comportamento mais adequado para um objeto de acordo com um contexto.

Padrão Strategy

• Os pontos fracos da solução implementada são:– Uso de if's e else's para testar opções de

pagamento e tomar o fluxo correto. – Um método que faz múltiplas coisas. Baixa

coesão.– A cada nova condição adicionada o código tona-se

mais complexo.

Padrão Strategy

Padrão Strategy

Padrão Strategy

Padrão Strategy

• Aspectos positivos– O algoritmo poder ser alterado sem a modificação

da classe Venda.– Novas implementações podem ser criadas e

introduzidas posteriormente.– Polimorfismo na chamada dos método que

executará a regra de pagamento.

Padrão Builder

• Builder propõe que o processo de construção de um objeto complexo, seja separado da definição do objeto, para que possamos ter diferentes algoritmos de construção permitindo diferentes representações para o objeto.

Padrão Builder

• Veja que o construtor dessa classe é extenso e difícil de entender.

Padrão Builder

Padrão Builder

• Veja que agora a regra de criação de objeto NotaFiscal

Padrão Builder

Padrão Composite

• Compor objetos em estrutura de árvore para representarem hierarquias todo-parte.

• Composite permite tratar de maneira uniforme objetos individuais e composições de objetos.

Padrão Composite • Classes composite (nó Galho): que poderão

conter outros componentes;• Classes leaf (nó Folha): que serão

componentes finais na hierarquia;

Padrão Composite

Exercício

• Aplique os conceitos relembrados aqui resolvendo os exercícios disponíveis na pasta da disciplina.