Exemplos práticos e didáticos sobre SOLID.
Rode yarn install e dentro de cada exemplo yarn install ; yarn test.
Alguns são evoluções de exemplos anteriores.
Note que cada um tem um README sobre ele dividido pelo seguinte:
- Configuração do projeto;
- Passos a seguir no desenvolvimento;
- Problema a ser resolvido;
- Regras;
- Objetivos;
- Ilustração;
- Abstrações;
- Roteiro (talvez).
Os princípios SOLID para programação e design orientados a objeto são de autoria de Robert C. Martin (mais conhecido como Uncle Bob) e datam do início de 2000.
A palavra SOLID é um acróstico onde cada letra significa a sigla de um princípio: SRP, OCP, LSP, ISP e DIP.
| Sigla | Nome | Descrição |
|---|---|---|
| SRP | Single Responsibility Principle | Uma classe deve ter um, e somente um, motivo para mudar. |
| OCP | Open Closed Principle | Você deve ser capaz de estender um comportamento de uma classe, sem modificá-lo. |
| LSP | Liskov Substitution Principle | As classes derivadas devem poder substituir suas classes bases. |
| ISP | Interface Segregation Principle | Muitas interfaces específicas são melhores do que uma interface geral. |
| DIP | Dependency Inversion Principle | Dependa de uma abstração e não de uma implementação. |
Os princípios SOLID devem ser aplicados no desenvolvimento de software de forma que o software produzido tenha as seguintes características:
- Seja fácil de manter, adaptar e se ajustar às constantes mudanças exigidas pelos clientes;
- Seja fácil de entender e testar;
- Seja construído de forma a estar preparado para ser facilmente alterado com o menor esforço possível;
- Seja possível de ser reaproveitado;
- Exista em produção o maior tempo possível;
- Que atenda realmente as necessidades dos clientes para o qual foi criado.
A utilização dos princípios SOLID tem o objetivo de evitar:
- Erros, Falhas e defeitos
- Estrutura de código ruim
- Código insustentável (difícil de manter)
- Desempenho sofrível
- Código de difícil compreensão
Utilizando esse principio você poderá garantir que qualquer alteração que venha a acontecer no código irá impactar somente seus dependentes diretos.
As entidades de (classes, módulos, funções) devem estar abertas para extensão, entretanto fechado para modificação
Utilizando esse princípio podemos garantir que as alterações sendo realizadas através de extensão da entidade base, nada será afetado no contexto dos códigos que utilizam a classe original.
O objetivo desse princípio é verificar que uma subclasse poderá ser substituída pela sua super classe sem quebrar a aplicação
Se Cigar/Beer/Water é subclasse de Product, os objetos do tipo Product podem ser substituidos por instâncias de Cigar/Beer/Water.
Não devemos ser forçados a depender das interfaces que não iremos utilizar. Esse princípio lida com as desvantagens da implementação de grandes interfaces únicas.
Separe os locais que tem forte acoplamento. Até um new AlgumaCoisa() pode gerar acoplamento.
Sempre que possível e fazer sentido, passe uma implementação abstraída em um método ou classe por parâmetro até onde ela será utilizada.