courses / mba-arquitetura-fullcycle / solid

S.O.L.I.D. (Aula do Uncle Bob)

Software apodrece com o tempo.

Apodrece pois há uma diminuição com o passar do tempo da produtividade, e essa redução é causada por código confuso/sujo

Pense em você tentando ser produtivo tentando fazer o jantar numa cozinha desarrumada com a bancada cheia de utensílios e restos da refeição anterior.

Código sujo é causado por devs negligêntes.

Negligência é contagiosa, vide Teoria das janelas quebradas

Sintomas do código confuso

Rigidez

Um sistema confuso é rigido. Ele resiste a mudanças, no sentido de que é dificil de evoluir. Causa: Alto acoplamento entre os módulos

Fragilidade

Dá pau com frequência e de forma inesperada, muitas vezes quando você mexe em algo aparentemente não relacionado (e que não deveria sê-lo)

É o sintoma que pode ser visto de forma mais clara

Imobilidade

O sistema tem módulos que poderiam ser úteis em outros contextos/sistemas, mas estão tão interconectaods que simplesmente não dá para move-los. Incapacidade de reutilizar componentes do software.

Remédios para código confuso

Todos estes sintomas tem como causa primária o "entanglement" (emaranhado - entendo como acoplamento, embora não entenda por que ele não utilizou "coupling")

Nosso objetivo com SOLID, e o objetivo do design de software em geral, é evitar este emaranhado

Os princípios ajudam a implementar "firewalls" que impedem mudanças de serem propagadas de forma idesejada, que bloqueiam a interdependência excessiva.

O principal mecanismo para isso é o princípio da inversão de dependência

O que é a inversão de dependência?

Pense que existem dois tipos de dependência. Uma dependência de código, que ocorre quando você invoca/importa/herda/declara/etc um determinado objeto. E a dependência de execução que é o que de fato ocorre quando o programa está rodando.

Inicialmente, e até hoje em projetos mal escritos, estas duas dependências tem o mesmo sentido: O módigo A invoca o módulo B

Porém, graças à orientação a objetos conseguimos inverter estas dependências: O módulo A invoca o módulo C, que por sua vez é apenas uma interface implementada por B Em tempo de execução, temos o fluxo de dependência de A para B, porém em código temos uma dependencia de A para C, e de B para C (inversão)

Princípios do SOLID

Single Responsability Principle - SRP

O nome é infeliz, passa uma idéia errada de o que o principio realmente é.

Uma class/modulo/etc deve ter apenas uma razão para mudar, muito embora possa sim ter mais de uma responsabilidade.

E o que causa as mudanças? Usuarios.

O princípio evita que um componente do qual voce dependa seja alterado de forma inesperada para atender a outro módulo

Open/Closed Principle

Artefatos de software precisam ser abertos para extensão e fechados para modificação

Como é isso? Você deve ser capaz de mudar o que o módulo faz, sem contudo alterar o módulo em si.

É possível? Quase sim. Alguns módulos serão abertos a modificação, contudo você pode limitar àquele código mais da raiz, mais proximo ao main, que inicializa e configura tudo no inicio da execução.

Essa proteção vem com os métodos ágeis, com sprints curtas, entregas frequentes, e feedbacks rápidos que permitem orientar o design às reais necessidades dos usuários

Este princípio poderia ser melhor nomeado como Single Source of Change Principle

Liskov Substitution Principle

Um usuário de um objeto de uma classe X deve poder receber em seu lugar um objeto deu ma classe Y que herdade X sem que seja capaz de notar a diferença.

Toda violação do LSP também implica numa violação do SRP por que forçará uma modificação na classe usuária para se adaptar ao novo subtipo

Interface Segregation Principle

Depender apenas do que você realmente precisa, então ao invés de depender de uma grande interface com muitas coisas que você não precisa, é melhor quebrar esta grande interface em elementos menores e mais concisos e depender apenas do que for realmente necessário

Dependency Inversion Principle

Dependa de abstrações.

Princípio por trás dos outros.

Não é necessário sempre