Padrões de Projeto

1. Catálogos

1.1. Factory Method

1.1.1. Um padrão que define uma interface para criar um objeto, mas permite às classes decidirem qual classe instanciar

1.2. Abstract Factory

1.2.1. Um padrão que define uma interface para criar um objeto, mas permite às classes decidirem qual classe instanciar

1.3. Adapter

1.3.1. Converte uma interface de uma classe para outra interface que o cliente espera encontrar

1.4. Bridge

1.4.1. Utilizado quando é desejável que uma interface (abstração) possa variar independentemente das suas implementações

1.5. Chain of Responsibility

1.5.1. Principal função é evitar a dependência entre um objeto receptor e um objeto solicitante

1.6. Command

1.6.1. Tem como definição encapsular uma solicitação como um objeto, o que lhe permite parametrizar outros objetos com diferentes solicitações

1.7. Iterator

1.7.1. Permite o acesso sequencial aos elementos de um conjunto sem expor sua implementação subjacente

1.8. Mediator

1.8.1. É um padrão de projeto comportamental que permite que você reduza as dependências caóticas entre objetos

1.9. Builder

1.9.1. Sugere que você extraia o código de construção do objeto de sua própria classe e o mova para objetos separados chamados builders

1.10. Prototype

1.10.1. É um padrão de projeto criacional que permite copiar objetos existentes sem fazer seu código ficar dependente de suas classes

1.11. Composite

1.11.1. Devem possuir um nome, que descreva o problema, as soluções e consequências

1.12. Decorator

1.12.1. É um padrão de projeto estrutural que permite adicionar comportamentos a um objeto dinamicamente, sem precisar alterar o código original do objeto

1.13. Memento

1.13.1. É um padrão de design comportamental que permite capturar e armazenar o estado interno de um objeto sem violar o encapsulamento

1.14. Observer

1.14.1. É um padrão de projeto comportamental que permite que um objeto notifique outros objetos sobre alterações em seu estado

1.15. State

1.15.1. É quando você tem um objeto que se comporta de maneira diferente dependendo do seu estado atual, quando o número de estados é enorme, e quando o código estado específico muda com frequência

1.16. Strategy

1.16.1. É um padrão de projeto comportamental que define uma família de algoritmos, garantindo que o algoritmo varie independentemente dos clientes que fazem uso dele

1.17. Singleton

1.17.1. Tem como definição garantir que uma classe tenha apenas uma instância de si mesma e que forneça um ponto global de acesso a ela

1.18. Facade

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

1.19. Flyweight

1.19.1. É um padrão de projeto de software apropriado quando vários objetos devem ser manipulados em memória sendo que muitos deles possuem informações repetidas

1.20. Template Method

1.20.1. Define os passos de um algoritmo e permite que a implementação de um ou mais desses passos seja fornecida por subclasses

1.21. Visitor

1.21.1. Permite que você defina uma nova operação sem alterar as classes dos elementos nos quais a operação atua

1.22. Proxy

1.22.1. Tem como objetivo proporcionar um espaço reservado para outro objeto controlar o acesso a ele

2. O que são?

2.1. são soluções típicas para problemas comuns em projeto de software

3. Benefícios

3.1. são um kit de ferramentas para soluções tentadas e testadas para problemas comuns em projeto de software.

3.2. Os padrões de projeto definem uma linguagem comum

4. Classificação

4.1. Idiomáticos: Básico e de Baixo nível

4.2. Arquitetônicos: Universais e de Alto nível

4.3. Grupos Principais de Padrões

4.3.1. Criacionais: mecanismos de criação de objetos que aumentam a flexibilidade e a reutilização de código

4.3.2. Estruturais: explicam como montar objetos e classes em estruturas maiores, enquanto ainda mantém as estruturas flexíveis e eficientes

4.3.3. Comportamentais: cuidam da comunicação eficiente e da assinalação de responsabilidades entre objetos

5. História

5.1. Primeiro conceitos de foi feito por Christopher Alexander, descrevia uma linguagem para o projeto de um ambiente urbano

5.2. Primeiro voltado a programação se deu com o livro GoF que mostrava 23 padrões que resolviam vários problemas de projeto orientado a objetos

6. Crítica

6.1. Gambiarras: necessidade de padrões surge quando uma linguagem de programação ou uma tecnologia que tem uma deficiência no nível de abstração

6.2. Soluções Ineficientes: os padrões tentam sistematizar abordagens que já são amplamente usadas

6.2.1. Essa unificação é vista por muitos como um dogma e eles implementam os padrões “direto ao ponto”, sem adaptá-los ao contexto de seus projetos