O Princípio de Segregação de Interface (Interface Segregation Principle – ISP) é o quarto pilar do SOLID e, embora pareça abstrato inicialmente, ele tem uma aplicação prática muito útil: tornar seu código mais modular, claro e fácil de manter.

Este artigo tem como objetivo demonstrar, de maneira acessível e direta, a aplicação do ISP no seu dia a dia de programação. Vamos falar sobre o que é, para que serve, quais são seus benefícios, dar exemplos de aplicação e ainda trazer um checklist para você saber se está aplicando o princípio corretamente no seu projeto.

O que é o Princípio de Segregação de Interface?

Esse princípio diz que “nenhum cliente deve ser forçado a depender de métodos que não utiliza”. Em outras palavras, significa que interfaces devem ser específicas para o que cada cliente (ou classe que as implementa) realmente precisa.  Assim, evitamos que uma classe precise implementar funções sem utilidade, só porque fazem parte da interface.

Interfaces “gordas” — ou seja, com muitos métodos que atendem a diferentes necessidades — são um problema. Elas geram dependências desnecessárias, dificultando a manutenção do código, pois alterações em uma função usada por um único consumidor podem afetar todos os demais que compartilham a interface.

Para que serve esse princípio no desenvolvimento de software?

Basicamente, o objetivo do ISP é tornar seu código mais organizado e adaptável. Ao dividir uma interface extensa em partes menores e focadas, cada usuário depende somente do que lhe é útil. Isso diminui a dependência excessiva, melhora a clareza e simplifica a correção de erros e o aprimoramento do projeto.

O ISP auxilia também na prevenção de erros complexos originados por modificações em funções que aparentam não afetar um certo usuário, mas que se encontram na mesma interface. A longo prazo, isso resulta em um código mais claro e duradouro.

Quais os benefícios de aplicar o ISP?

• Redução de acoplamento: cada classe implementa apenas as interfaces que realmente precisa.
• Maior coesão: interfaces menores e mais específicas tornam a intenção do código mais clara.
• Facilidade de manutenção: mudanças em uma interface pequena impactam menos clientes.
• Testes mais simples: é mais fácil criar mocks e stubs para interfaces menores.
• Maior reutilização: interfaces específicas podem ser mais facilmente reaproveitadas em diferentes contextos.

Exemplo prático: separando interfaces “gordas”

Esse exemplo que vou dar abaixo eu retirei do livro “Mergulho nos Padrões de Projeto” do Alexander Shvets, é um livro que indico bastante para quem quer aprender mais sobre fundamentos da programação. Vamos ao exemplo:

Imagine que você criou uma biblioteca para simplificar a conexão de aplicativos a vários fornecedores de serviços na nuvem. No começo, o desenvolvimento foi focado na nuvem da Amazon, com compatibilidade total para todos os seus serviços e recursos.

Naquela época você acreditava que as demais plataformas teriam capacidades semelhantes às da Amazon. Mas, conforme você ia adicionando suporte para um novo provedor, você percebeu que a interface da sua biblioteca estava grande demais. Seu código tinha muitos métodos que só faziam sentido para a Amazon e que não se aplicavam aos outros provedores.

Algo assim:

Transformando isso em código Python nós teríamos algo como:

from abc import ABC, abstractmethod

# Interface genérica que tenta atender todos os provedores
class CloudProvider(ABC):
    
    @abstractmethod
    def store_file(self, name):
        pass

    @abstractmethod
    def get_file(self, name):
        pass

    @abstractmethod
    def create_server(self, region):
        pass

    @abstractmethod
    def list_servers(self, region):
        pass

    @abstractmethod
    def get_cdn_address(self):
        pass


# Implementação da Amazon com todos os métodos
class AmazonCloudProvider(CloudProvider):

    def store_file(self, name):
        print(f"Armazenando {name} na Amazon Cloud")

    def get_file(self, name):
        print(f"Recuperando {name} da Amazon Cloud")

    def create_server(self, region):
        print(f"Criando servidor na região {region} (Amazon)")

    def list_servers(self, region):
        print(f"Listando servidores da região {region} (Amazon)")

    def get_cdn_address(self):
        return "cdn.amazon.com/meucdn"


# Implementação do Dropbox, com métodos que ele não suporta "vazios"
class DropboxCloudProvider(CloudProvider):

    def store_file(self, name):
        print(f"Armazenando {name} no Dropbox")

    def get_file(self, name):
        print(f"Recuperando {name} do Dropbox")

    def create_server(self, region):
        raise NotImplementedError("Dropbox não suporta criação de servidores.")

    def list_servers(self, region):
        raise NotImplementedError("Dropbox não tem suporte para listar servidores.")

    def get_cdn_address(self):
        raise NotImplementedError("Dropbox não oferece endereço CDN.")

Para melhorar seu código, a melhor abordagem seria quebrar a interface em partes, criando interfaces mais refinadas:

Que transformado em código Python seria:

from abc import ABC, abstractmethod

# Interface focada só em armazenamento de arquivos
class CloudStorageProvider(ABC):
    
    @abstractmethod
    def store_file(self, name):
        pass

    @abstractmethod
    def get_file(self, name):
        pass


# Interface focada em hospedagem (criação e listagem de servidores)
class CloudHostingProvider(ABC):

    @abstractmethod
    def create_server(self, region):
        pass

    @abstractmethod
    def list_servers(self, region):
        pass


# Interface focada em entrega de conteúdo (CDN)
class CDNProvider(ABC):

    @abstractmethod
    def get_cdn_address(self):
        pass


# A Amazon oferece todos os serviços, então implementa todas as interfaces
class AmazonCloudProvider(CloudStorageProvider, CloudHostingProvider, CDNProvider):

    def store_file(self, name):
        print(f"Amazon armazenando o arquivo {name}")

    def get_file(self, name):
        print(f"Amazon recuperando o arquivo {name}")

    def create_server(self, region):
        print(f"Amazon criando servidor na região {region}")

    def list_servers(self, region):
        print(f"Amazon listando servidores na região {region}")

    def get_cdn_address(self):
        return "cdn.amazon.com/meucdn"


# O Dropbox só faz armazenamento, então implementa só o necessário
class DropboxCloudProvider(CloudStorageProvider):

    def store

Resumo do que mudou:

• Agora temos interfaces menores e específicas, respeitando o Princípio da Segregação de Interface (ISP).
• O Dropbox não é mais forçado a implementar métodos que ele não usa.
• O código ficou mais limpo e fácil de manter.

Caso você queira um outro exemplo, recomendo esse vídeo do canal Vamos Codar

Como saber se seu código segue o Interface Segregation Principle?

Se você está iniciando, é natural ter dúvidas. Aqui vão algumas perguntas que você pode se fazer ao analisar suas interfaces:

• Esta interface possui métodos que nem todos os clientes realmente precisam?
• Alguma classe está implementando métodos com corpo vazio ou com comentários como “não se aplica”?
• Se eu mudar um método da interface, quantos clientes serão impactados?
• Eu conseguiria dividir essa interface em duas ou mais, agrupando métodos por contexto ou responsabilidade?
• Os nomes dos métodos têm uma relação clara entre si ou parecem resolver problemas muito diferentes?

Essas perguntas ajudam a identificar quando é hora de aplicar o ISP e refatorar.

Aplicando o ISP no dia a dia: boas práticas

Veja algumas dicas práticas para aplicar o Princípio de Segregação de Interface de forma natural no seu código:

• Pense em papéis: cada interface deve representar um papel ou responsabilidade clara.
• Use nomes específicos: interfaces como Salvavel, Exportavel ou Imprimivel são mais expressivas do que interfaces genéricas.
• Evite métodos genéricos demais: nomes como executar() ou processar() podem indicar falta de foco.
• Combine interfaces quando necessário: em linguagens como Java ou TypeScript, é possível compor interfaces (ex: interface A extends B, C).
• Faça revisões frequentes: com o crescimento do código, pode ser necessário revisitar e dividir interfaces antigas.

Conclusão: menos é mais quando se trata de interfaces

O Princípio de Segregação de Interface é uma ferramenta poderosa para quem busca escrever código limpo, modular e fácil de manter. Mesmo como desenvolvedor júnior, você pode começar a aplicar esse conceito hoje mesmo. Basta observar suas interfaces e pensar: esse conjunto de métodos faz sentido para todos os clientes?

Esse post faz parte da minha série sobre os princípios SOLID. Se você ainda não viu os anteriores, vale a pena conferir para entender como cada um deles contribui para um design de software mais robusto e escalável!

E você, já aplicou o Princípio de Segregação de Interface no seu código? Que dificuldades encontrou? Compartilha com a gente nos comentários!

FAQ: dúvidas comuns sobre o ISP

• O ISP se aplica apenas a linguagens com interface explícita?
  Não! O conceito se aplica a qualquer linguagem orientada a objetos, mesmo que use contratos implícitos, como no Python ou Ruby.
• Segregar interfaces pode gerar muita fragmentação?
  Sim, se for feito em excesso. O ideal é buscar um equilíbrio entre granularidade e clareza.
• Posso combinar várias interfaces pequenas em uma grande?
  Sim, desde que a nova interface represente uma composição natural dos papéis originais.
• Como o ISP se relaciona com o princípio da responsabilidade única (SRP)?
  Ambos incentivam coesão. O SRP foca em classes, enquanto o ISP foca em interfaces.