1. Padrão GoF
   1. Padrões de Criação
      1. Abstract Factory
         1. Permite a criação de famílias de objetos relacionados ou dependentes por meio de uma única interface e sem que a classe concreta seja especificada.
      2. Builder
         1. Permite a separação da construção de um objeto complexo da sua representação, de forma que o mesmo processo de construção possa criar diferentes representações.
      3. Factory Method
         1. Permite as classes delegar para subclasses decidirem. O factory method permite delegar a instanciação para as subclasses.
      4. Prototype
         1. Permite a criação de objetos a partir de um modelo original, ou protótipo.
      5. Singleton
         1. Garante a existência de apenas uma instância de uma classe, mantendo um ponto global de acesso ao seu objeto.
   2. Padrões Estruturais
      1. Definição
         1. Padrões estruturais "se preocupam com a forma como classes e objetos são compostos para formar estruturas maiores". Segundo eles, "os padrões estruturais de classes utilizam a herança para compor interfaces ou implementações". Os padrões estruturais de objetos, por sua vez, "descrevem maneiras de compor objetos para obter novas funcionalidades".
         2. Os padrões estruturais tratam problemas referentes à estrutura de classes e objetos. Ou melhor, de como vencer as limitações da estrutura da programação orientada a objetos para tornar as aplicações mais flexíveis.
         3. Você usará o padrão Adapter quando quiser usar uma classe existente, mas sua interface não corresponder àquela que você necessita.
      2. Adapter
         1. Permite que classes com interfaces incompatíveis possam interagir.
         2. Exemplo:
            1. Vamos imaginar o seguinte cenário. Você tem uma aplicação que conversa com dois bancos de dados. Um deles é relacional, baseado em tabelas e registros. O outro é orientado a documentos, trabalha com o conceito de chave-valor. Existem duas classes prontas para persistir dados nesses dois bancos, respectivamente RecordManager e DocumentManager.
            2. O problema é que os métodos de persistência são diferentes. A classe RecordManager tem um método save() que recebe um objeto da classe Record. A classe DocumentManager, por sua vez, tem um método chamado persist() que recebe uma variável HashMap<String,String>. E na aplicação, os objetos que contêm os dados para serem persistidos são da classe AbstractEntity.
            3. Se pudéssemos fazer uma analogia com o mundo físico, poderíamos dizer que você tem que ligar dois aparelhos em um quadro de tomadas. Esse quadro recebe tomadas de dois pinos chatos. Só que seus dois aparelhos tem plugues completamente diferentes. Um tem dois pinos cilíndricos e o outro, pra piorar, tem três pinos chatos, só que em disposição diferente do que a tomada espera.
      3. Bridge
         1. Utilizado quando é desejável que uma interface (abstração) possa variar independentemente das suas implementações.
      4. Composite
         1. Constituído pela composição de objetos similares a ele; Utilizado para representar listas recorrentes - ou recursivas - de elementos; Permite que os elementos contidos em um objeto composto sejam tratados como se fossem um único objeto.
      5. Decorator
         1. Permite adicionar um comportamento a um objeto já existente em tempo de execução, ou seja, agrega dinamicamente responsabilidades adicionais a um objeto.
         2. O padrão Decorator deve ser utilizado quando você precisa acrescentar e/ou remover responsabilidades de objetos individuais de forma dinâmica (em tempo de execução). O padrão Decorator também permite que você combine as funcionalidades de várias classes em uma sem estabelecer uma ligação obrigatória, superando as limitações da herança simples do Java. E observe que a arquitetura do Decorator permite que você "herde" somente os comportamentos que interessam. Como a classe "decorada" não sabe o que os "decoradores" fazem além do que foi definido pela interface comum, não há sobrecarga de atributos e métodos.
         3. Problema
            1. Quando queremos que classes diferentes compartilhem características comuns, criamos uma superclasse, que reúna tudo o que for genérico. Isso, porém, tem limitações.
            2. O estabelecimento de herança é algo estático, que deve estar definido antes da execução do programa. Não é possível definir generalizações em tempo de execução.
            3. Outra questão é que em Java, especificamente, não há herança múltipla. Isso significa que só é possível herdar características e comportamentos de uma única classe, de forma direta.
            4. Vamos imaginar a seguinte situação. Nós temos uma classe chamada Carta, que monta uma carta. Uma carta pode ter os seguintes elementos: endereço, data, endereço do destinatário, referências, saudação, o texto, a conclusão, a assinatura e o post-scriptum. Observe o verbo: pode ter, não deve ter.
            5. Isso significa que uma carta pode ser uma combinação desses elementos, que não estarão, obrigatoriamente, todos juntos. Sendo assim, ter uma classe Carta que crie todos esses elementos implica ter recursos que não serão usados sempre, exceto o elemento texto. Se você quiser montar uma carta que tenha somente saudação e texto, por exemplo, o que fará?
            6. É claro que você pode ter atributos que omitam a criação dos elementos na montagem da carta, mas isso não removerá o comportamento desnecessário que a classe encapsula. Seria melhor que o comportamento pudesse ser adicionado ao objeto em tempo de execução. Que ao criar o objeto, nós pudéssemos dizer o que ele pode fazer.
            7. Para resolver isso, podemos usar o padrão Decorator.
      6. Facade
         1. Disponibiliza uma interface simplificada para uma das funcionalidades de uma API.
      7. Flyweight
         1. Apropriado quando vários objetos devem ser manipulados, e esses não suportam dados adicionais.
      8. Proxy
         1. Classe que funciona como uma interface para outra classe.
         2. Quando você precisar que um objeto tenha um substituto, que trate todas as demandas que não têm relação direta com ele, é sinal de que deve aplicar o padrão Proxy.
         3. O Proxy também serve para limitar a quantidade de recursos disponíveis em uma API. Às vezes uma API possui uma série de recursos, e uma miríade de modos de fazer alguma coisa. Se os programadores tiverem a liberdade de usar a API diretamente, sem uma padronização, podem criar um sério problema de manutenção, decorrente da complexidade gerada pela falta de legibilidade do código. Quer dizer, ações similares são executadas pela aplicação de modo diferente de acordo com a pessoa que implementou.
         4. Um modo de forçar a padronização é criar Proxies para as classes da API, limitando as formas possíveis de manipulá-la.
         5. Problema
            1. Em algumas situações, criar um objeto de uma determinada classe é algo caro ao sistema. Se o objeto faz uso intensivo de recursos externos do sistema que afetam o desempenho, como leitura e gravação de disco, ou qualquer comunicação com dispositivos externos, não faz sentido criá-lo nem mantê-lo se ele não será utilizado. E pode ocorrer que a configuração dos atributos do objeto, necessária para a execução dos métodos que se comunicam com os recursos externos, ocorra em momentos diferentes da aplicação, de modo que ele só abrirá conexões com recursos, mas só as utilizará depois de algum tempo.
            2. Seria ideal que isso ocorresse por demanda. Que nós criássemos o objeto, configurássemos de uma vez tudo o que fosse necessário e executássemos os métodos que precisamos.
            3. Vamos imaginar, por exemplo, uma classe chamada Pdf, que cria arquivos PDF. Ela permite que nós criemos o documento, montemos as páginas, incluamos o conteúdo nas páginas e montemos o índice. Com tudo isso definido, ela nos permite gravar o documento, ou criá-lo de verdade, em um disco, onde fique persistente.
            4. O problema é que essa classe já abre um recurso para gravação de arquivo quando é instanciada. E a configuração de todos os seus atributos, para geração do arquivo, pode ser feita em momentos diferentes, fazendo com que um recurso fique aberto por um intervalo de tempo em que não é utilizado.
            5. Nós poderíamos ter alguma forma de adiar a instanciação do objeto, até que tivéssemos realmente todos os dados necessários para criar o arquivo, configuração e chamada do método gerador em sequência, de uma só vez.
   3. Padrões Comportamentais
      1. Chain of Responsability
         1. Representa um encadeamento de objetos receptores para o processamento de uma série de solicitações diferentes. Esses objetos receptores passam a solicitação ao longo da cadeia até que um ou vários objetos a tratem.
      2. Command
         1. Encapsular uma solicitação como um objeto, desta forma permitindo que clientes parametrizem diferentes solicitações, enfileirem ou façam o registro (log) de solicitações e suportem operações que podem ser desfeitas.
      3. Interpreter
         1. Utilizado para representar e resolver problemas recorrentes que possam ser expressos sob a forma de uma linguagem formal simples.
      4. Iterator
         1. Permite a um programador examinar um container.
      5. Mediator
         1. Desacopla e gerencia as colaborações entre um grupo de objetos. Define um objeto que encapsula as interações dentro desse grupo.
      6. Memento
         1. Permite armazenar o estado interno de um objeto em um determinado momento, para que seja possível retorná-lo a este estado, caso necessário.
      7. Observer
         1. Define uma dependência um-para-muitos entre objetos de modo que quando um objeto muda o estado, todos seus dependentes são notificados e atualizados automaticamente. Permite que objetos interessados sejam avisados da mudança de estado ou outros eventos ocorrendo num outro objeto.
      8. State
         1. Usado quando o comportamento de um objeto muda, dependendo do seu estado.
      9. Strategy
         1. Permite definir novas operações sem alterar as classes dos elementos sobre os quais opera. Definir uma família de algoritmos e encapsular cada algoritmo como uma classe, permitindo assim que elas possam ser trocados entre si. Este padrão permite que o algoritmo possa variar independentemente dos clientes que o utilizam.
      10. Template Method
          1. Fornece uma estrutura fixa, de um algoritmo, esta parte fixa deve estar presente na superclasse, sendo obrigatório uma classeAbstrata que possa conter um método concreto.
      11. Visitor Pattern
          1. Permite que se crie uma nova operação sem que se mude a classe dos elementos sobre as quais ela opera.
2. Padrão GRASP
   1. Controller
   2. Creator
   3. Expert
   4. High Cohesion
   5. Indirection
   6. Law of Demeter
   7. Low Coupling
   8. Polymorphism
3. Padrão J2EE
   1. Camada de Apresentação
      1. Intercepting Filter
      2. Front Controller
      3. Application Controller
      4. Context Object
      5. View Helper
      6. Composite View
      7. Dispatcher View
      8. Service To Worker
   2. Camada de Negócio
      1. Application Service
      2. Business Delegate
      3. Service Locator
      4. Session Facade
      5. Transfer Object
      6. Business Object
      7. Value List Handler
      8. Composite Entity
      9. Transfer Object Assembler
   3. Camada de Integração
      1. Service Activator
      2. Domain Store
      3. Web Service Broker
      4. Data Access Object