Padrão de Projeto de Software

...

Catálogo de padrões de projeto

Os padrões de projeto variam conforme sua granularidade (partes pequenas) e no seu nível de abstração, como existem diversos padrões, (GAMMA et al. 1995) sugere uma maneira de organizá-los em critérios. Por critério de finalidade ou propósito, onde indica o que o padrão faz e por critério de escopo que especifica se o padrão se aplica a classes ou objetos.

[pic 1]

Ilustração 1. Espaço dos padrões de projeto (GAMMA et al. 2000)

Padrões de criação

Os padrões de criação abstraem o processo de instanciação, ajudam a tornar o sistema independente de como seus objetos são criados, compostos e representados (GAMMA et al. 1995), ou seja, são relacionados a criação dos objetos.

Abstract Factory (kit ou toolkit)

Proposta: Permitir a criação de famílias de objetos inter-relacionados através da utilização de uma classe abstrata.

[pic 2]

Ilustração 2. Abstract Factory (GAMMA et al. 1995)

Builder

Proposta: Separar 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.

[pic 3]

Ilustração 3. Builder (GAMMA et al. 1995)

Factory Method (Virtual constructor)

Proposta: Definir interface para criar um objeto, mas deixar as subclasses decidirem que classe instanciar.

[pic 4]

Ilustração 4. Factory Method (GAMMA et al. 1995)

Prototype

Proposta: Especificar os tipos de objetos a serem criados e criar novos objetos pela cópia desse protótipo.

[pic 5]

Ilustração 5. Prototype (GAMMA et al. 1995)

Singleton

Proposta: Garantir que uma classe tenha somente uma instância e seja global.

[pic 6]

Ilustração 6. Singleton (GAMMA et al. 1995)

Padrões estruturais

Os padrões estruturais se preocupam com a forma como classes e objetos são compostos para formar grandes estruturas (GAMMA et al. 1995), portanto, tratam das associações entre classes e objetos.

Adapter

Proposta: Converte a interface de uma classe em outra interface. Permite que classes incompatíveis trabalhem em conjunto.

[pic 7]

Ilustração 7. Adpter (GAMMA et al. 1995)

Bridge

Proposta: Separa uma abstração de sua implementação, de modo que as duas podem variar independentemente.

[pic 8]

Ilustração 8. Bridge (GAMMA et al. 1995)

Composite

Proposta: Compor objetos em estruturas de árvores simples.

[pic 9]

Ilustração 9. Composite (GAMMA et al. 1995)

Decorator

Proposta: Adicionar responsabilidade dinâmica aos objetos.

[pic 10]

Ilustração 10. Decorator (GAMMA et al. 1995)

Façade

Proposta: Fornece uma interface unificada para um conjunto de interfaces em um subsistema.

[pic 11]

Ilustração 11. Façade (GAMMA et al. 1995)

Flyweight

Proposta: Facilita a reutilização de muitos objetos de granulação fina, tornando a utilização de um grande número de objetos mais eficientes.

[pic 12]

Ilustração 12. Flyweight (GAMMA et al. 1995)

Proxy

Proposta: Um objeto que representa outro objeto.

[pic 13]

Ilustração 13. Proxy (GAMMA et al. 1995)

Padrões comportamentais

Os padrões comportamentais se preocupam com algoritmos e atribuições de responsabilidades entre classes e objetos (GAMMA et al. 1995).

Chain of Responsibility

Proposta: Passar um pedido entre uma cadeia de objetos.

[pic 14]

Ilustração 14. Chain of responsibility (GAMMA et al. 1995)

Command

Proposta: Encapsular uma solicitação de comando como um objeto.

[pic 15]

Ilustração 15. Command (GAMMA et al. 1995)

Interpreter

Proposta: Define a representação de uma gramática de determinada linguagem.

[pic 16]

Ilustração 16. Interpreter (GAMMA et al. 1995)

Iterator

Proposta: Acessar sequencialmente os elementos de uma coleção.

[pic 17]

Ilustração 17. Iterator (GAMMA et al. 1995)

Mediator

Proposta: Define comunicação