Este curso faz parte da formação Arquitetura e Design de Projetos Java da Alura Cursos, e este repositório tem como finalidade registrar o aprendizado obtido durante as aulas.
- Single Responsability Principle
- Open Closed Principle
- Liskov Substitution Principle
- Interface Segregation Principle
- Dependency Inversion Principle
Esses 5 princípios são uma ferramenta poderosa para mantermos um código de fácil entendimento, fácil refatoração e com o menor número possíveis de bugs. Antes de falarmos sobre eles, acho importante destacarmos os 3 pilares do Paradigma da Programação Orienta a Objetos: Coesão, Encapsulamento e Acoplamento.
Se consultarmos o dicionário, encontraremos que coesão nada mais é que a união harmônica entre uma coisa e outra. Levando para o mundo do desenvolvimento de software, a união harmônica seria as coisas que tem dentro de uma classe. Os atributos e métodos devem estar em harmonia, devem estar unidos e devem representar coisas em comum. Será que é a responsabilidade da classe Funcionário de fazer uma consulta, um serviço externo, buscar, fazer essa chamada a uma API externa, fazer um tratamento ou coisas do gênero? Então talvez aí já estava fungindo aquela harmonia citada anteriormente. A classe está fazendo coisas demais, então ela deveria ter uma responsabilidade única. Coesão é isso, ter classes que fazem apenas uma única coisa. Classes não coesas tendem a crescer indefinidamente, o que as tornam difíceis de manter.
Proteger, blindar uma classe contra influências externas, contra manipulações externas que podem prejudicar a consistência das informações. Quando temos classes não encapsuladas, isso faz com que tenhamos violações da regra de negócio do projeto, além de aumentar o acoplamento. Importante frisar que encapsulamento não é apenas colocar os atributos como private e adicionar getters e setters.
A ideia de você acoplar é quando você tem dois componentes que estão interligados entre si causando uma dependência entre eles. Uma classe A chama uma classe B. Acoplamento forte: quando a alteração em uma classe impacta em diversas outras.
Vamos aos princípios do SOLID
Foco em coesão. "Uma classe deveria ter apenas um único motivo para mudar" (Robert (Uncle Bob) Martin)
Uma classe deve ser especializada em um único assunto e possuir apenas uma responsabilidade dentro do software, ou seja, a classe deve ter uma única tarefa ou ação para executar.
Princípio do aberto fechado. Entidades de software, entidades entendam como, classes, módulos, funções ou coisas do gênero, elas deveriam estar sempre abertas para extensão para você adicionar coisas novas, novos comportamentos, porém fechadas para modificação. Isso significa que devemos poder criar novas funcionalidades e estender o sistema sem precisar modificar muitas classes já existentes.
Uma classe derivada deve ser substituível por sua classe base. Objetos podem ser substituídos por seus subtipos sem que isso afete a execução correta do programa.
"Uma classe não deveria ser forçada a depender de métodos que não utilizará" (Robert (Uncle Bob) Martin)
A ideia é que abstrações não devem depender de implementações. A abstração deve ser totalmente abstrata. Ela não depende de nenhuma implementação específica. A implementação sim é que deveria depender de uma abstração.
- O que é SOLID: O guia completo para você entender os 5 princípios da POO
- Coesão, encapsulamento e acoplamento os pilares da orientação a objetos.
- POO: tudo sobre Programação Orientada a Objetos!
- SOLID: guia completo sobre os 5 princípios da POO!
- Guia Básico sobre Princípios de Programação e SOLID
Este projeto encontra-se em desenvolvimento e está aberto para pull request.
Feito com ❤ por Irla Andrade 👋🏽 Entre em contato:
