public class Cozinheiro
{
    void PrepararAlimentos();
    void Cozinhar();
    void MontarPrato();
}

public class Garcom
{
    void AnotarPedido();
    void ServirMesa();    
}

public class Caixa
{
    void FinalizarConta();
    void ReceberPagamento();
}

Agora, observamos classes bem segregadas com os métodos específicos. Refatorando a God Class temos um código mais compreensivo, isolado e de fácil identificação de bugs e rápida solução dos mesmos.

Vantages:

• Motivo único de alteração da entidade
• Reaproveitamento de código
• Fácil refatoração
• Testes unitários com implementação facilitada
• Isolamento de bugs e agilidade de atuação nos mesmos
• Melhor entendimento do código por outros analistas/desenvolvedores

Dica:

Se houver dificuldade para nomear uma entidade, com um nome totalmente descritivo e ao mesmo tempo curto/breve. É um indício de que a entidade tem mais do que uma responsabilidade.

Open/Closed Principle ::: Princípio Aberto e Fechado

O OCP dita que uma entidade está aberta para extensão e fechada para modificação.

De modo simples, a entidade está fechada para ser alterada. Muitas vezes, alguns programadores se vêem motivados a modificar uma entidade e colocar um "if" para resolver uma nova situação nova que surja. Justificando que é apenas uma condição, mas esquecendo que qualquer que seja a outra entidade que possa herdar desta também será afetada e ainda mais, não levando em conta que em futuro breve ou não, outras condicionais poderão surgir, fazendo com que o código fique poluído e difícil de ser entendido e dada a devida manutenção.

E ela está aberta para ser extendida, quando outras entidades podem usá-la por herança e adicionar novas funcionalidades.

Mudar é sempre um risco, extender é garantir que o que estava implementado continue a funcionar e a nova regra de negócio será apenas para uma extensão de algo que já está funcional.

Exemplo:

public interface IAutomovel 
{
    void Move();
    void Buzina();
}

public class Entregador
{
    public void Dirigir(IAutomovel automovel)
    {
        automovel.Move();
    }
    
    public void AvisarChegada(IAutomovel automovel)
    {
        automovel.Buzina();
    }

}

Neste exemplo o entregador não está limitado a um tipo de veículo, bem como a interface IAutomovel pode ser usada como extensão para diversos outros cenários, como: carros específicos e/ou outros tipos de condutores (piloto, motorista de ônibus, motociclista, etc).

Vantages:

• Redução de complexidade ciclomáticas* e elimando cláusulas condicionais
• Reaproveitamento de código, por extender uma entidade filha ao invés de modificar a entidade pai
• Fácil refatoração
• Testes unitários com implementação facilitada
• Isolamento de bugs e agilidade de atuação nos mesmos
• Melhor entendimento do código por outros analistas/desenvolvedores

Dica:

Se o código possui "Ifs" com a intenção de validar todas as variáveis externas que surgiram é um alerta de que a OCP deve ser olhado com carinho.

Liskov Substitution Principle ::: Princípio de Substituíção de Liskov

LSP prega que uma entidade base poderá ser substituída por uma entidade derivada, sem prejuízo para o software e que as entidades derivadas nunca devem infligir as definições/comportamentos da entidade base.

O LSP, tem foco nas abstrações e para que seu princípio seja obedecido, refatora-se a abstração base para um nível que realmente possa atender de forma genérica, sem obrigar que as entidades derivadas façam testes lógicos ("Ifs") para evitar exceções. Em outras palavras, nos fornece uma forma de saber se uma herança está implementada em um nível correto ou não. Através do uso de polimorfismo, ao usar um método ou propriedade, seja da classe base ou da classe especialista, o resultado sempre deve estar correto sem qualquer alteração.

Exemplo:

public class Integrador
{
    public void EnviaEmail(string conteudo)
    {
        // Obtem o conteudo...
        // Envia para alguem
    }
}

public class Sistema
{
    public void Integra()
    {
        Integrador integrador = new Integrador();
        integrador.EnviaEmail("Conteudo!");
    }
}

Caso precisemos adicionar uma integração via API, vamos precisar adicionar mais um metodo no nosso integrador e provavelmente um if no nosso metodo Sistema.Integra(). Alem disso a nossa classe Sistema precisa "entender" que tipo de integração ele vai fazer(API ou Email).

Para evitar isso, podemos, mais uma vez, usar interfaces!

public interface IIntegrador
{
    void Envia(string conteudo);
}

public class IntegradorEmail : IIntegrador
{
    public void Envia(string conteudo)
    {
        // Faz lógica de EMAIL
    }
}

public class IntegradorAPI : IIntegrador
{
    public void Envia(string conteudo)
    {
        // Faz a lógica de API
    }
}

public class Sistema
{
    public void Integra(IIntegrador integrador)
    {
        integrador.Envia("Conteudo!");
    }
}

Agora o Sistema não precisa saber se o envio do e-mail é por meio de uma API, SMTP ou qualquer outra tecnologia.

Vantages:

• Provoca o nível correto e necessário de abstração
• Reaproveitamento de código, por extender uma entidade filha ao invés de modificar a entidade pai (Implanta OCP)
• Fácil refatoração
• Testes unitários com implementação facilitada
• Isolamento de bugs e agilidade de atuação nos mesmos
• Melhor entendimento do código por outros analistas/desenvolvedores

Dica:

Se o código possui "Ifs" com a intenção de validar todas as variáveis externas que surgiram é um alerta de que a LSP deve ser olhado com carinho. Quanto a essa dica a diferença existente entre o LSP e OCP é que o LSP foca exclusivamente na abstração.

Interface Segregation Principle ::: Princípio de Segregação de Interface

ISP tem como princípio que os clientes* que implementam uma interface não devem ser obrigados a implementar uma ação/método que não utiliza.

O ISP é a aplicação dos princípios SRP, OCP e LSP, direcionandos para interfaces.

Exemplo:

public interface IVeiculo
{
    void Abastecer(string combustivel);
    void FecharPortas();
    void LevantarTripe();
    void Mover();    
    void Estacionar(); 
}

public class Carro : IVeiculo
{
    public void Abastecer(string combustivel) { }

    public void FecharPortas() { }

    public void LevantarTripe()
    {
        throw new System.Exception("Não tem tripé!");
    }
    
     public void Mover() { }
     
     public void Estacionar() { }

}

public class Moto : IVeiculo
{
    public void Abastecer(string combustivel) { }

    public void FecharPortas()
    {
        throw new System.Exception("Não tem portas!");
    }
    
    public void LevantarTripe() { }
    
    public void Mover() { }
     
    public void Estacionar() { }
}

Até o presente momento, conseguimos notar que tanto a classe Carro, como a classe Moto foram obrigados a implementar métodos que não podem executar.
Uma das abordagens corretas deveria ser, conforme abaixo.

public interface IVeiculo
{
    void Abastecer(string combustivel);
    void Mover();    
    void Estacionar(); 
}

public interface ICarro
{
    void FecharPortas();
}

public interface IMoto
{
    void LevantarTripe();
}

public class Carro : IVeiculo, ICarro
{
    public void Abastecer(string combustivel) { }    
    
    public void Mover() { }
     
    public void Estacionar() { }
     
    public void FecharPortas() { }
}

public class Carro : IVeiculo, IMoto
{
    public void Abastecer(string combustivel) { }    
    
    public void Mover() { }
     
    public void Estacionar() { }
     
    public void LevantarTripe() { }
}

Agora chegamos ao nível correto de segregação das interfaces e desobrigamos a implementação a tratar com excessões ações que a interface exigia dela e a implementação como cliente não poderia executar.

Vantages:

• Provoca o nível correto e necessário de abstração na interface
• Reaproveitamento de código, por se criar interfaces mais específicas do que genéricas, lembrando que uma classe que implementa pode, se necessário, implementar várias interfaces.
• Fácil refatoração
• Testes unitários com implementação facilitada
• Isolamento de bugs e agilidade de atuação nos mesmos
• Melhor entendimento do código por outros analistas/desenvolvedores

Dica:

Se um cliente precisar "passar por alto" algum método da interface e/ou a atualização da interface* provoque este mesmo efeito em outras classes que já estão implementadas é sinal de que o ISP está sendo infligido.
Observação: alterar uma interface, para incluir um novo método é extremamente perigoso, visto que pode quebrar o software de diversas formas diferentes. Isto apenas se deve ser feito no caso específico de que todas as implementações necessitem deste novo método.

Dependency Inversion Principle ::: Princípio da Inversão de Dependência

DIP determina que módulos de alto nível não devem depender de módulos de baixo nível. Ambos devem depender de abstrações e abstrações não devem depender de detalhes. Detalhes devem depender de abstrações.

O DIP em poucas palavras diz "Dependa de uma abstração e não de uma implementação".
Olhando para as vantagens descritas abaixo, nota-se que o DIP é, por assim dizer, o mais importante de todos os princípios. Já que sua aplic