Princípios SOLID: Interface Segregation

1. Introdução ao Princípio da Segregação de Interfaces

O Princípio da Segregação de Interfaces (ISP) é o quarto dos cinco princípios SOLID, formalizado por Robert C. Martin no final dos anos 1990. Sua definição é direta: "nenhum cliente deve ser forçado a depender de métodos que não usa". Em essência, o ISP defende que interfaces grandes e monolíticas devem ser decompostas em interfaces menores e mais específicas, cada uma atendendo a um conjunto coeso de responsabilidades.

Historicamente, o ISP surgiu como uma resposta a problemas observados em sistemas orientados a objetos onde interfaces inchadas criavam acoplamentos desnecessários. Diferente dos princípios de Responsabilidade Única (SRP) e Aberto/Fechado (OCP), que focam em classes e módulos, o ISP atua diretamente no contrato entre componentes. Na Arquitetura de Software, o ISP é fundamental para manter baixo acoplamento e alta coesão, permitindo que sistemas evoluam sem que mudanças em um módulo propaguem efeitos colaterais para outros.

2. Problemas de Interfaces "Gordas" (Fat Interfaces)

Considere uma interface monolítica para um sistema de gerenciamento de documentos:

public interface IDocumentManager
{
    void Open(string path);
    void Save();
    void Print();
    void Scan();
    void SendEmail(string recipient);
    void Archive();
    void Encrypt();
    void Decrypt();
}

Um cliente que apenas precisa abrir e salvar documentos é forçado a implementar métodos como Scan(), SendEmail() e Encrypt(). Isso viola o ISP porque o cliente depende de funcionalidades que nunca utilizará. As consequências incluem:

  • Violação do Open/Closed Principle: qualquer alteração em métodos não utilizados pode exigir modificações em múltiplos clientes.
  • Manutenção custosa: implementações vazias ou com throw new NotImplementedException() proliferam, tornando o código frágil.
  • Dependências ocultas em sistemas distribuídos: em microsserviços, uma interface inchada em um contrato REST ou gRPC pode forçar todos os consumidores a lidar com endpoints irrelevantes, aumentando o acoplamento entre serviços.

3. Identificando Violações do ISP no Código

Padrões comuns que indicam violações do ISP incluem:

Métodos com exceções não implementadas:

public class SimpleDocumentReader : IDocumentManager
{
    public void Open(string path) { /* implementação real */ }
    public void Save() { /* implementação real */ }
    public void Print() { throw new NotImplementedException(); }
    public void Scan() { throw new NotImplementedException(); }
    public void SendEmail(string recipient) { throw new NotImplementedException(); }
    public void Archive() { throw new NotImplementedException(); }
    public void Encrypt() { throw new NotImplementedException(); }
    public void Decrypt() { throw new NotImplementedException(); }
}

Classes abstratas com implementações vazias que servem apenas para satisfazer contratos não utilizados são outro sinal. Além disso, dependências indesejadas entre módulos — onde um módulo de domínio precisa referenciar bibliotecas de infraestrutura apenas porque a interface que implementa exige métodos de persistência — indicam falta de segregação.

4. Estratégias de Refatoração para Aplicar o ISP

A refatoração começa pela identificação dos papéis distintos que uma interface monolítica desempenha. No exemplo anterior, podemos segregar em interfaces menores:

public interface IOpenable
{
    void Open(string path);
}

public interface ISavable
{
    void Save();
}

public interface IPrintable
{
    void Print();
}

public interface IScannable
{
    void Scan();
}

public interface IEmailSender
{
    void SendEmail(string recipient);
}

public interface IArchivable
{
    void Archive();
}

public interface IEncryptable
{
    void Encrypt();
    void Decrypt();
}

Agora, um SimpleDocumentReader pode implementar apenas IOpenable e ISavable. Para cenários que exigem múltiplas capacidades, a composição de interfaces é preferível à herança múltipla:

public class AdvancedDocumentProcessor : IOpenable, ISavable, IPrintable, IEncryptable
{
    public void Open(string path) { /* ... */ }
    public void Save() { /* ... */ }
    public void Print() { /* ... */ }
    public void Encrypt() { /* ... */ }
    public void Decrypt() { /* ... */ }
}

O padrão Adapter também é útil quando não podemos modificar uma interface legada. Um adapter pode expor uma interface segregada para o cliente, traduzindo chamadas para a interface monolítica subjacente.

5. ISP e a Arquitetura em Camadas

Em uma arquitetura em camadas típica (domínio, aplicação, infraestrutura, apresentação), o ISP atua na definição dos contratos entre camadas. Por exemplo, uma interface de repositório deve expor apenas operações relevantes para a camada de domínio:

public interface IUserRepository
{
    User GetById(Guid id);
    void Save(User user);
    void Delete(Guid id);
}

Uma interface de serviço, por sua vez, pode agregar múltiplas operações de repositórios diferentes, mas ainda assim deve ser coesa:

public interface IUserService
{
    User RegisterUser(string name, string email);
    void ChangeEmail(Guid userId, string newEmail);
    UserProfile GetProfile(Guid userId);
}

A granularidade ideal evita que uma interface de repositório exponha métodos de relatório ou de administração que seriam usados apenas pela camada de apresentação. Isso facilita a substituição de implementações — por exemplo, trocar um banco de dados relacional por um NoSQL sem impactar a camada de serviço.

6. ISP em Sistemas Distribuídos e Microsserviços

Em microsserviços, o ISP se aplica aos contratos de API. Uma interface de serviço REST inchada pode forçar todos os consumidores a lidar com endpoints que não utilizam. Por exemplo, um serviço de pedidos que expõe:

POST /orders
GET /orders/{id}
PUT /orders/{id}/cancel
POST /orders/{id}/refund
GET /orders/{id}/audit-log

Um cliente que apenas cria pedidos (POST) e consulta status (GET) depende desnecessariamente dos endpoints de cancelamento, reembolso e log de auditoria. A segregação ideal seria expor interfaces separadas:

// Interface de criação e consulta
POST /orders
GET /orders/{id}

// Interface de gerenciamento (separada)
PUT /orders/{id}/cancel
POST /orders/{id}/refund

// Interface administrativa
GET /orders/{id}/audit-log

Em mensageria, o ISP sugere que eventos e mensagens sejam específicos para cada consumidor, evitando que um serviço precise filtrar campos irrelevantes de uma mensagem genérica.

7. Boas Práticas e Armadilhas Comuns

A armadilha mais comum é a segregação excessiva, levando à proliferação de interfaces com um único método. Isso viola o princípio KISS (Keep It Simple, Stupid) e pode tornar o sistema difícil de navegar. O equilíbrio está em agrupar métodos que são sempre usados juntos pelos mesmos clientes.

Outra armadilha é confundir ISP com DRY (Don't Repeat Yourself). O ISP não exige que você elimine duplicação de código; ele exige que você separe papéis. Métodos que realizam a mesma operação em contextos diferentes podem pertencer a interfaces distintas.

Boas práticas incluem:
- Projetar interfaces do ponto de vista do cliente: pergunte "o que este cliente precisa fazer?" em vez de "o que este componente pode fazer?"
- Preferir composição sobre herança: uma classe pode implementar múltiplas interfaces pequenas em vez de herdar de uma grande.
- Revisar interfaces regularmente: à medida que novos clientes surgem, avalie se a interface ainda é coesa.

8. Conclusão e Integração com os Demais Princípios SOLID

O ISP é essencial para a manutenibilidade do software. Ele reduz o acoplamento, aumenta a coesão e facilita a evolução independente de módulos. O ISP se conecta diretamente com o Princípio da Inversão de Dependência (DIP), pois interfaces segregadas são mais estáveis e menos propensas a mudanças, permitindo que módulos de alto nível dependam de abstrações estáveis. Também se relaciona com o Princípio da Substituição de Liskov (LSP), já que implementações de interfaces segregadas tendem a ser mais fáceis de substituir sem quebrar o sistema.

Checklist final para avaliar se uma interface está bem segregada:
1. Cada cliente que implementa a interface usa todos os seus métodos?
2. Nenhum método da interface lança NotImplementedException ou tem implementação vazia?
3. A interface tem um nome que reflete um papel ou responsabilidade única?
4. Mudanças em um método da interface não afetam clientes que não o utilizam?
5. A interface pode ser implementada por classes de diferentes camadas sem dependências desnecessárias?

Se a resposta para todas as perguntas for "sim", sua interface está provavelmente bem segregada.

Referências