Os Princípios S.O.L.I.D
O princípio S.O.L.I.D. é uma coleção de cinco princípios de design de software que ajudam os desenvolvedores a escrever código limpo, flexível e de fácil manutenção. Cada letra do acrônimo S.O.L.I.D. representa um princípio específico:
S - Single Responsibility Principle (Princípio da Responsabilidade Única):
Esse princípio diz que uma classe (ou módulo) deve ter apenas uma responsabilidade, ou seja, deve fazer apenas uma coisa. Isso torna o código mais claro e fácil de entender, porque cada parte do programa tem uma função específica.
O - Open/Closed Principle (Princípio do Aberto/Fechado):
Esse princípio sugere que uma classe deve estar aberta para extensão, mas fechada para modificação. Isso significa que você pode adicionar novas funcionalidades a uma classe sem precisar alterar o código existente. Isso torna o código mais flexível e menos propenso a erros.
L - Liskov Substitution Principle (Princípio da Substituição de Liskov):
Esse princípio diz que você deve poder substituir uma classe base (ou superclasse) por uma de suas subclasses sem alterar o comportamento esperado do programa. Isso garante que todas as subclasses sejam compatíveis com a classe base e torna o código mais coeso.
I - Interface Segregation Principle (Princípio da Segregação de Interfaces):
Esse princípio afirma que as interfaces devem ser específicas para os clientes que as usam. Em outras palavras, é melhor ter interfaces pequenas e especializadas, em vez de interfaces grandes e genéricas. Isso evita que as classes tenham que implementar métodos desnecessários e melhora a coesão do código.
D - Dependency Inversion Principle (Princípio da Inversão de Dependência):
Esse princípio sugere que as classes de alto nível não devem depender das classes de baixo nível diretamente, mas sim de abstrações. Isso permite que você troque facilmente as implementações das classes de baixo nível sem afetar as classes de alto nível. Isso torna o código mais flexível e fácil de manter.
Esses princípios são muito importantes para escrever código de qualidade e manter um bom design de software. Eles ajudam a tornar o código mais modular, flexível e fácil de entender, o que facilita a manutenção e evita problemas futuros.
Lembre-se de que esses conceitos podem ser um pouco complexos, mas com prática e experiência, você começará a aplicá-los naturalmente ao escrever seu próprio código.
Compartilhe sua opnião sobre o que foi dito, se concorda ou não concorda com tal parte. Você é livre para expressar sua opnião!
Ao responder esse tópico com alguns exemplos, vou aproveitar para exercitar "o pensar sobre o assunto" visto que venho estudando, procurando entender e aplicar os Princíos SOLID.
Aqui vai um exemplo que todo programador entenderá "Máquina de Café" :D
S - Single Responsibility Principle (Princípio da Responsabilidade Única):
Se vc tem uma classe Máquina de Café você pode precisar de vários comportamentos (métodos), desde métodos para preparar cada tipo de bebida e métodos para verificar os insumos, até métodos para verificar se a máquina está sem problemas de comunicação com o sistema de pagamentos, porém isso não pode ficar "tudo junto e misturado", tem métodos ou responsabilidades que são da Máquina de Café e outras responsabilidades são da Bebida. Spoiler: aqui já conseguimos visualizar a necessidade de "fatiar o sistema" e aplicabilidade dos demais princípios :D
O - Open/Closed Principle (Princípio do Aberto/Fechado):
Pensando na Classe Máquina de Café ao invés de ter um monte de "IF" para decidir qual modo de preparar cada tipo de bebida, você pode encapsular cada bebida em sua própria classe e usar uma abstração entre a "bebida concreta" e a "Máquina de Café", ficaria assim:
class MaquinaCafe {
PrepararBebida(IBebida bebida, quantidadeAcucar){
bebida.Preparar(quantidadeAcucar);
}
}
interface IBebida {
Preparar(int quantidadeAcucar);
}
class CafeSemLeite implements IBebida {
Preparar(int quantidadeAcucar){
//misturar café solúvel + água + qtd açucar.
}
}
class CafeComLeite implements IBebida {
Preparar(int quantidadeAcucar){
//misturar café solúvel + leite + qtd açucar.
}
}
class Chocolate implements IBebida {
Preparar(int quantidadeAcucar){
//misturar chocolate em pó + leite + qtd açucar.
}
}
class Capuccino implements IBebida {
Preparar(int quantidadeAcucar){
//misturar aqui ingredientes do capuccino.
}
}
L - Liskov Substitution Principle (Princípio da Substituição de Liskov):
Vamos ver como esse princípo funciona analisando uma forma de quebrar ele: Considerando o exemplo das Bebidas da Máquina de Café, se ao invés de uma interface utilizarmos uma classe abstrata e essa abstração ou classe base possuir um método AdicionarLeite(), e ao implementar as demais classes que herdam de Bebida, a classe CafeSemLeite não implementaria este método pois a bebida é sem leite, então essa classe não poderia substituir a sua classe base na implementação pois mudaria o comportamento do sistema. Isso nos mostra que só devem ser colocados na classe base os comportamentos comuns e que não serão suprimidos nas subclasses, uma subclasse não deve suprimir o comportamento da classe que está acima dela.
I - Interface Segregation Principle (Princípio da Segregação de Interfaces):
Ex: aqui podemos usar o mesmo exemplo da Máquina de Café e Bebidas e analisar que nem todas as bebidas são açucaradas então poderíamos ter uma interface IAcucarada para implementar na bebida que possui açucar e deixar as bebidas que não são açucaradas sem implementar essa interface.
D - Dependency Inversion Principle (Princípio da Inversão de Dependência):
Aqui podemos analisar o exemplo da Máquina de Café e Bebidas e ver que a Máquina de Café não tem a implementação do método Preparar fazendo uma 'receita de preparo' para cada bebida, ao contrário ela chama (através da abstração) o método Preparar que está encapsulado dentro de cada Bebida.
PS: Se em algum ponto alguém entender que precisa e quiser me corrigir, ou complementar ou mostrar um exemplo mais simples, fiquem a vontade :D
[]'s
Só uma pequena correção: SOLID é um acrônimo que engloba 5 princípios, e não é um princípio.
Também não entendi bem como os exemplos mostram a aplicação de cada um deles. Alguns parecem até que nem ilustram corretamente (se eu especulei certo).
Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente. Para saber quando, me segue nas suas plataformas preferidas. Quase não as uso, não terá infindas notificações (links aqui).
Que massa essas explicações sobre cada principio. Já tinha visto SOLID de outra forma, mas abstrair tudo desta forma, realmente fica muito mais palpavel o conhecimento hahahaha parabens!