Executando verificação de segurança...
1

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

Carregando publicação patrocinada...