• Ramon Ferreira Silva

ISP: O Princípio da Segregação de Interfaces

Atualizado: 22 de Ago de 2019

Segregação de Interfaces


O Princípio da Segregação de Interfaces é o quarto princípio SOLID, e corresponde a letra “I”.


Definição


Este princípio nos diz que uma classe consumidora não deve conhecer (depender) métodos que não necessitam.


Para ter uma classe coesa e reutilizável, devemos atribuir  a ela uma única responsabilidade .

Mas as vezes, mesmo essa única responsabilidade pode ser quebrada em responsabilidades menores ainda, tornando sua interface mais amigável.


Violando o Princípio da Segregação de Interfaces

abstract class Funcionario{
    private float salarioBase;
    private String cargo;
    private String nome;
    
    public float getSalarioBase(){
        return this.salarioBase;
    }
    
    abstract float getSalario();
    abstract float getComissao();
}

class Vendedor extends Funcionario {
    private float totalVendas;
    
    public float getSalario(){
        return this.salarioBase + this.getComissao();
    }
    
    public float getComissao(){
        return this.totalVendas * 0.1;
    }
}

class Representante extends Funcionario {
    private float totalVendas;
    
    public float getSalario(){
        return 0.0f;
    }
    
    public float getComissao(){
        return this.totalVendas * 0.3;
    }
}

class AtendenteDeCaixa extends Funcionario {
   
    public float getSalario(){
        return this.getSalarioBase();
    }
    
    public float getComissao(){
        return 0.0f;
    }
}

Nos temos aqui 4 classes, a classe abstrata Funcionário que possui a lógica básica de um Funcionário, temos Vendedor que é um Funcionário, mas possui um própria lógica de calcular o seu salário e a sua comissão. Temos o Representante que não é exatamente um funcionário, pois não recebe um salário base, porém recebe uma comissão maior sobre suas vendas. E por fim Atendente de Caixa que é um funcionário mas não recebe comissão.


Com isso temos vários problemas de Design aí. O primeiro é, Representante não é um funcionário, mas está se passando c como tal para reaproveitar a responsabilidade de

Receber um “Salário de Comissionado”, o segundo problema é, o Atende de Caixa não precisa saber como calcular comissão, mas é obrigado a implementar um método getComissao().


Aplicando o Princípio da Segregação de Interfaces


Aplicando o Princípio da Segregação de Interfaces, iremos fazer uma refatoração no código, e aplicando o método de refatoração Extrair Interface, para extrair as interfaces Assalariado e Comissionável.

interface Assalariado{
    float getSalario();
}

interface Comissionavel(){
    float getComissao();
}

abstract class Funcionario implements Assalariado {
    private float salarioBase;
    private String cargo;
    private String nome;
    
    @override
    public float getSalario(){
        return this.salarioBase;
    }
}

class Vendedor extends Funcionario implements Comissionavel  {
    private float totalVendas;
    
    @overrride
    public float getSalario(){
        return this.salarioBase + this.getComissao();
    }

    @override
    public float getComissao(){
        return this.totalVendas * 0.1;
    }
}

class Representante implements Comissionavel {
    private float totalVendas;
    
    @override
    public float getComissao(){
        return this.totalVendas * 0.3;
    }
}

Primeiro extraímos as interfaces da Classe Funcionário que deixou de ser abstrata e não possui mais dos métodos abstratos getSalario() e getComissao(). Mas como funcionário ainda recebe um salário, então a classe Funcionário passou a ter a Interface Assalariado, obrigando-a a implementar o método getSalario(). Assim a classe Atendente de Caixa perdeu o sentido de existir e passou ser representada como um Funcionário.


Já a nossa classe Vendedor, que é um funcionário, pois extende a classe Funcionário que é um Assalariado. Mas como Vendedor possui sua própria maneira de calcular o salário, então sobrescrevemos o método getSalario(), para que contemple essa sua lógica. E como Vendedor possui uma comissão,  implementamos a interface Comissionavel, para poder calcular sua comissão.


Por fim a classe Representante que não é mais trata como um funcionário, implementará apenas a interface Comissionavel, assim podemos ter o seu calculo de comissão, não mais precisamos mais ter conhecimento sobre salário.


Conclusão


O princípio da Segregação de Interfaces nos ajuda a aumentar a granularidade de nossos objetos, aumentando a coesão de suas interfaces e diminuindo drasticamente o acoplamento. E isso melhora a manutenção do nosso código, pois interfaces mais simples são mais fácies de serem entendidas e implementadas.


Até a próxima.


#ArquiteturadeSoftware #CódigoLimpo #Refatoração #SOLID

0 visualização