S.O.L.I.D
"Bons sistemas de software começam com um código limpo. Por um lado, se os tijolos não são bem feitos, a arquitetura da construção perde a importância. Por outro lado, você pode fazer uma bagunça considerável com tijolos bem feitos. É ai que entram os princípios SOLID."
Bob defende que os princípios SOLID nos diz como organizar as funções e estruturas de dados em classes e como essas classes devem se relacionar.
Single Responsibility Principle - S.R.P
Um módulo deve ser responsável por apenas um ator. Um módulo pode ser entendido como sendo um grupo coeso de funções e estruturas de dados. A forma de identificar a violação desse principio, é observando se uma classe faz o que não deve. Exemplo: classe Funcionário tem método para calcularPagamento, algo que deveria ser feito por um departamento de contabilidade, etc. Basicamente, o SRP diz para separarmos o código que diferentes atores dependam dele.
Caso um módulo tenha suas partes quebradas em muitas outras para atender a esse princípio, talvez o padrão Facade seja uma solução.
Em um nível arquitetural, esse princípio aparece como o "Eixo de mudança (Axis of change)", responsável pela criação de limites arquiteturais.
Open Closed Principle - O.C.P
O princípio do aberto-fechado defende que algo deve estar aberto para crescimento mas fechado para mudanças. Um exemplo disso, é considerarmos uma interface que gera relatórios financeiros. Essa interface não deve depender de mudanças em classes de baixo nível usadas para satisfazer a necessidade de gerar relatórios, digo, claro que são elas que fazem o trabalho pesado, mas a interface não deve mudar em detrimento do código contido nas classes de baixo nível. Todavia, essa interface deve estar aberta para carregar novos comportamentos.
O objetivo da OCP consiste em fazer com que o sistema seja fácil de entender sem que a mudança cause um alto impacto. Para isso, organizamos um sistema em uma hierarquia de dependência que proteja os níveis mais altos das mudanças dos componentes de nível mais baixo.
Liskov Substitution Principle - L.S.P
Em 1988, Barbara Liskov escreveu: "O que queremos aqui é algo como a seguinte propriedade de substituição: se para cada objeto o1 de tipo S, houver um objeto o2 de tipo T, de modo que, para todos os programas P definidos em termos de T, o comportamento de P não seja modificado quando o1 for substituído por o2, então S é um subtipo de T."
Para entender essa ideia, podemos considerar uma cobrança (Sistema) de licença (Interface) de uso de algum software, com os planos empresariais (impl 1) e pessoais (impl 2). A cobrança (sistema) não depende de uma implementação específica, visto que a licença (interface) abstrai esses detalhes, então, quando for empresarial ou pessoal, o comportamento da cobrança não será quebrado.
Implementações não devem influenciar o consumo da interface.
Interface Segregation Principle - I.S.P
Uma classe não deve implementar uma interface que carrega operações das quais não são interessantes para a classe.
Em geral, o autor defende que é prejudicial depender de módulos que contenham mais elementos do que você precisa. Depender de coisas que você não precisa pode causar problemas inesperados.
Dependency Inversion Principle - D.I.P
Segundo esse principio, os sistemas mais flexíveis dependem mais de abstrações do que de implementações.
Em geral, a ideia é limitar a dependência de nossas implementações a abstrações ou implementações que são estáveis, que raramente mudam. Por isso devemos considerar usar mais abstrações do que implementações, pois as interfaces normalmente não mudam tanto quanto uma implementação.
Esse parágrafo corresponde a ideia de Design de Software 101.
Para seguir esse princípio, temos as seguintes práticas:
- Não se refira a classes concretas voláteis;
- Não derive de classes concretas voláteis;
- Não sobrescreva funções concretas;
Precisamos estabelecer que existe um limite arquitetural dentro de nossas aplicações, de forma que todas as regras de negócio possam sem compreendidas em uma camada abstrata, que não dependa diretamente de uma camada concreta e volátil.
Sinto que não há muito o que se comentar sobre esse capítulo, pois é basicamente uma escrita do autor sobre os princípios SOLID, sem grandes comentários adicionais.
Top comments (0)