Os princípios SOLID —ISP

Interface segregation principle (ISP) — Princípio da segregação de interface

Continuando do artigo anterior, vamos falar agora sobre o quarto princípio, ISP.

O ISP, princípio da segregação de interface, diz que “Nenhum cliente deve ser forçado a depender de métodos que não utiliza”.

Em outras palavras, podemos entender que as classes que implementam interfaces, ou são filhas de classes abstratas, devem implementar todos os métodos, e todos os métodos devem fazer sentido dentro do contexto da classe.

Vamos à prática. Um estagiário é um colaborador de uma empresa, com direitos como qualquer funcionário CLT. Entretanto, os estagiários não possuem todos os “direitos”, como por exemplo, o 13º salário.

<?php
interface Funcionario
{
    public function getCargo();
    public function calculaSalario();
    public function calcula13o();
}
class Gerente implements Funcionario
{
    public function getCargo()
    {
        return "Gerente";
    }
    public function calculaSalario()
    {
        //logica para calculo salário
    }
    public function calcula13o()
    {
        //logica para calculo do 13
    }
}
class Programador implements Funcionario
{
    public function getCargo()
    {
        return "Programador";
    }
    public function calculaSalario()
    {
        //logica para calculo salário
    }
    public function calcula13o()
    {
        //logica para calculo do 13
    }
}
class Estagiario implements Funcionario
{
    public function getCargo()
    {
        return "Estagiário";
    }
    public function calculaSalario()
    {
        //logica para calculo salário
    }
    public function calcula13o()
    {
        throw new Exception("Estagiário não pode receber 13o");
    }
}

Neste exemplo, temos uma violação do ISP, pois um funcionário contratado pela CLT recebe 13º salário, já o estagiário não. Então, o código deveria prever isso de forma que a classe não precise implementar um método não utilizado, apenas para cumprir o contrato da interface.

<?php
interface Funcionario
{
    public function getCargo();
    public function calculaSalario();
}
interface FuncionarioCeletista extends Funcionario
{
    public function calcula13o();
}
interface FuncionarioEstagiario extends Funcionario
{
    public function setInstituicaoEnsino();
}
class Gerente implements FuncionarioCeletista
{
    public function getCargo()
    {
        return "Gerente";
    }
    public function calculaSalario()
    {
        //logica para calculo salário
    }
    public function calcula13o()
    {
        //logica para calculo do 13
    }
}
class Programador implements FuncionarioCeletista
{
    public function getCargo()
    {
        return "Programador";
    }
    public function calculaSalario()
    {
        //logica para calculo salário
    }
    public function calcula13o()
    {
        //logica para calculo do 13
    }
}
class Estagiario implements FuncionarioEstagiario
{
    public function getCargo()
    {
        return "Estagiário";
    }
    public function calculaSalario()
    {
        //logica para calculo salário (bolsa)
    }
    public function setInstituicaoEnsino()
    {
        //logica para definir instituição de ensino do estagiário
    }
}

Ao modificarmos as interfaces, agora temos os contratos corretos para cada situação, estagiário e celetista. A aplicação, quando receber uma instância de Funcionario saberá quais métodos poderá executar. Para a situação do 13º salário, precisará necessariamente de uma instância de FuncionarioCeletista , uma vez que somente este possui esta função, e assim não precisando se preocupar em fazer validações extras.

Espero que tenham gostado. O próximo artigo será sobre o DIP - Princípio da inversão de dependência.

Os códigos estão no repositório: https://github.com/felippeduarte/medium/tree/master/solid