SOLID

• S - Single Responsibility Principle (Princípio da Responsabilidade Única)

  • Cada classe deve ter um, e somente um, motivo para mudar.

  • Tentar nomear suas classes ou métodos com tudo que eles são capazes de fazer.

  • Se uma classe tem várias responsabilidades, mudar um requisito do projeto pode trazer várias razões para modificar a classe. Por isso, as classes devem ter responsabilidades únicas.

  • Vantagens:

    • Facilidade para fazer manutenções

    • Reusabilidade das classes

    • Facilidade para realizar testes

    • Simplificação da legibilidade do código

• O - Open Closed Principle (Princípio Aberto-Fechado)

  • Entidades de software (como classes e métodos) devem estar abertas para extensão, mas fechadas para modificação.

  • 

  • O ideal é adaptar o código não para alterar a classe, mas para estendê-la. Em geral, isso é feito quando abstraímos um código para uma interface.

  • Pense em um caminhão: toda a sua implementação, como motor, bateria e cabine é fechada para modificação, porém, podemos estender as tarefas que ele realiza dependendo da carroceria que anexamos.

• L - Liskov Substitution Principle (Princípio de Substituição de Liskov)

  • Classes derivadas (ou classes-filhas) devem ser capazes de substituir suas classes-base (ou classes-mães).

  • Ou seja, uma classe-filha deve ser capaz de executar tudo que sua classe-mãe faz. Esse princípio se conecta com o polimorfismo.

  • Conseguimos substituir um pai por um filho completamente.

  • Caso um método de uma classe-filha tenha um retorno muito diferente do da classe-mãe, ou lance uma exceção, por exemplo, já dá para perceber que algo está errado.

• I - Interface Segregation Principle (Princípio de Segregação de Interface)

  • Devemos criar interfaces específicas ao invés de termos uma única interface genérica.

  • Uma classe não deve ser forçada a implementar interfaces e métodos que não serão utilizados.

  • Exemplo da comissão para vendedor e não para recepcionista.

    

• D - Dependency Inversion Principle (Princípio da Inversão de Dependência)

  • Dependa de abstrações e não de implementações concretas.

  • É recomendado que os módulos de alto nível não dependam diretamente dos detalhes de implementação de módulos de baixo nível.

  • A classe PedidoService está diretamente acoplada à implementação concreta da classe PedidoRepository.

    
    

• Podemos criar uma interface para a classe de acesso ao banco de dados e injetá-la na classe 'PedidoService'. Dessa forma, nós estamos dependendo de abstrações e não de implementações concretas.