Design de Patterns

Padrões de projetos com SOLID e Design Patterns.

Sugestão de estudo sobre Clean Code:

SOLID

Coesão:

Uma classe coesa faz bem uma única coisa. Classes coesas não devem ter várias responsabilidades.

Encapsulamento:

Getters e setters não são formas eficientes de aplicar encapsulamento. É interessante fornecer acesso apenas ao que é necessário em nossas classes. O encapsulamento torna o uso das nossas classes mais fácil e intuitivo.

Acoplamento:

Acoplamento é a dependência entre classes. Acoplamento nem sempre é ruim, e que é impossível criar um sistema sem nenhum acoplamento. Devemos controlar o nível de acoplamento na nossa aplicação.

#Single Responsibility Principle

Uma classe deve ter um e apenas um motivo para ser alterada.
Que classes/métodos/funções/módulos devem ter uma única responsabilidade bem definida.

#Open Closed

Um sistema deve ser aberto para a extensão, mas fechado para a modificação.
Que cada classe deve conhecer e ser responsável por suas próprias regras de negócio.

#Liskov Substitution Principle

Devemos poder substituir classes base por suas classes derivadas em qualquer lugar, sem problema (composição e herança).
Que, embora a herança favoreça o reaproveitamento de código, ela pode trazer efeitos colaterais quando não utilizada da maneira correta.

#Interface Segregation Principle

Diz que implementações devem depender de abstrações e abstrações não devem depender de implementações.
Que as interfaces são menos propensas a sofrer mudanças enquanto implementações podem mudar a qualquer momento.

#Dependency Inversion Principle

Que as interfaces devem definir apenas os métodos que fazem sentido para seu contexto.
Diz que uma classe não deve ser obrigada a implementar um método que ela não precisa

DESIGN PATTERNS I (Comportamentais)

Gang of Four (GoF)

#Strategy

Diminuir a complexidade do nosso código, trocando múltiplas condicionais por classes.
É um padrão de design comportamental que permite definir uma família de algoritmos, colocar cada um deles em uma classe separada e tornar seus objetos intercambiáveis.

#Chain of Responsibility

Use o padrão quando for essencial executar vários manipuladores em uma ordem específica, e a diferenciar casos onde padrões semelhantes podem ser aplicados.
É um padrão de design comportamental que permite passar solicitações ao longo de uma cadeia de manipuladores.
Ao receber uma solicitação, cada manipulador decide processar a solicitação ou passá-la para o próximo manipulador da cadeia.

#Template Method

Criação de um método concreto na classe “mãe”, que chama métodos abstratos implementados nas classes “filhas”.
É um padrão de design comportamental que define o esqueleto de um algoritmo na superclasse, mas permite que as subclasses substituam etapas específicas do algoritmo sem alterar sua estrutura.

#State

Se o resultado de uma chamada de método depende do estado, podemos delegar esta ação para uma classe específica do estado atual.
É um padrão de design comportamental que permite que um objeto altere seu comportamento quando seu estado interno muda.
"Parece que o objeto mudou de classe".

#Command e Command Handler

Que um caso de uso em nossa aplicação pode ter várias ações (salvar no banco, enviar e-mail, etc).
Que um caso de uso deve ser extraído para uma classe específica, ao invés de estar no arquivo da CLI, controller ou algo do tipo.
É um padrão de design comportamental que transforma uma solicitação em um objeto autônomo que contém todas as informações sobre a solicitação.

#Observer

Que é mais interessante separar cada ação em uma classe separada.
Definir um mecanismo de assinatura para notificar vários objetos sobre quaisquer eventos que ocorram com o objeto que estão observando.

DESIGN PATTERNS II (Estruturais)

Gang of Four (GoF)

#Adapter

Quando precisamos utilizar código legado ou código de componentes externos em nosso sistema.
Use a classe Adapter quando quiser usar alguma classe existente, e sua interface não for compatível com o restante do seu código.

#Decorator

Permite anexar novos comportamentos a objetos colocando esses objetos dentro de uma class abstract que contêm os novos comportamentos.
Use o padrão Decorator quando precisar atribuir comportamentos extras a objetos em tempo de execução sem quebrar o código que usa esses objetos.

#Composite

É um padrão de projeto estrutural que permite compor objetos em estruturas de árvore e, em seguida, trabalhar com essas estruturas como se fossem objetos individuais.
Use o padrão Composite quando precisar implementar uma estrutura de objeto semelhante a uma árvore.

#Facade

Em determinados casos, nós podemos precisar de um acesso simplificado a uma parte complexa ou grande do nosso sistema, como autenticação, acesso a sistema de arquivos, cache, etc. Uma classe de fachada, contendo apenas a funcionalidade desejada, pode ser bastante útil.
Use o padrão Facade quando precisar ter uma interface limitada, mas direta, para um subsistema complexo.

#Proxy

Um proxy controla o acesso ao objeto original, permitindo que você execute algo antes ou depois que a solicitação chegar ao objeto original.
Inicialização lenta (proxy virtual). É quando você tem um objeto de serviço pesado que desperdiça recursos do sistema por estar sempre ativo, mesmo que você só precise dele de vez em quando.
Solicitações de registro (proxy de registro). É quando você deseja manter um histórico de solicitações para o objeto de serviço.

dya-andrade / design-patterns-java Goto Github PK

design-patterns-java's Introduction