Princípio da Segregação de Interfaces (ISP) - TypeScript & React

Resumo: Domine o Princípio da Segregação de Interfaces (ISP). Aprenda conceitos SOLID com exemplos práticos em TypeScript e React para escrever código mais limpo e fácil de manter.

Introdução

O Princípio da Segregação de Interfaces (ISP) diz que nenhum cliente deve ser forçado a depender de métodos que não usa. Quando aplicado corretamente, o ISP reduz o acoplamento, facilita testes e torna o código mais simples de entender e evoluir. Este guia apresenta conceitos e exemplos práticos em TypeScript e React que você pode aplicar hoje para deixar sua base de código mais modular e sustentável. Para entender o contexto do ISP dentro dos princípios SOLID, veja recursos clássicos sobre SOLID e boas práticas de design de software¹.

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

Imagine um controle remoto com 90 botões quando tudo que você precisa é o botão “play”. Essa frustração é semelhante a uma classe que implementa uma interface extensa e sem foco. O ISP incentiva projetar interfaces pequenas e específicas para cada cliente, evitando o anti‑padrão da “interface gorda” (ou “God interface”). Interfaces menores tornam sistemas mais claros, flexíveis e fáceis de testar.⁵

Por que interfaces gordas prejudicam

• Dependências desnecessárias: classes ficam acopladas a métodos que nunca usam, tornando mudanças arriscadas.
• Sobrecarga cognitiva: desenvolvedores têm de vasculhar métodos irrelevantes para encontrar o que precisam.
• Implementações vazias: classes criam stubs para métodos não usados, adicionando boilerplate.

A ideia central é simples: dê a cada cliente exatamente o que ele precisa, e nada mais. Isso melhora legibilidade, testabilidade e permite mudanças locais sem efeitos colaterais globais.

Interfaces monolíticas vs. segregadas

Uma comparação lado a lado mostra as vantagens do ISP.

Escolher o ISP ajuda sua base de código a permanecer adaptável conforme funcionalidades são adicionadas ou refatoradas.

ISP na prática: violações comuns

Violações do ISP raramente quebram o app imediatamente, mas tornam a manutenção dolorosa. Procure por classes com muitos métodos vazios ou componentes frontend com um grande número de props opcionais.

Uma clássica “God Interface” em TypeScript

// ANTI‑PATTERN: uma "fat interface" que viola o ISP
interface IUserActions {
  createUser(data: UserData): void;
  editUser(id: string, data: UserData): void;
  deleteUser(id: string): void;
  viewUserProfile(id: string): UserProfile;
  changeUserRole(id: string, newRole: Role): void;
  publishArticle(article: Article): void;
  approveComment(commentId: string): void;
}

Uma classe Viewer forçada a implementar isso terá métodos sem sentido ou que lançam erros. Isso aumenta custo e risco de manutenção.

Props inchadas em componentes React

Um sintoma comum no frontend é um componente Card genérico com muitas props opcionais. Isso cria ambiguidade sobre combinações válidas de props e força renderizações condicionais complexas.

// ANTI‑PATTERN: props inchadas
interface CardProps {
  title: string;
  description?: string;
  imageUrl?: string;
  imageAltText?: string;
  videoUrl?: string;
  authorName?: string;
  authorAvatarUrl?: string;
  publicationDate?: string;
  articleLink?: string;
  onClick?: () => void;
  // ... muitas props opcionais
}

Esses anti‑padrões preparam o terreno para refatorações estruturadas.

Como refatorar: de interfaces monolíticas para segregadas

Refatorar para ISP não exige reescritas radicales. Use mudanças incrementais para dividir responsabilidades e clarificar contratos.

1) Consertando a "God Interface" em TypeScript

Passo A: identifique papéis de clientes (por exemplo: admins, editores, visualizadores).

Passo B: crie interfaces específicas por papel.

// GOOD: interfaces focadas
interface IViewerActions {
  viewUserProfile(id: string): UserProfile;
}

interface IEditorActions {
  publishArticle(article: Article): void;
  approveComment(commentId: string): void;
}

interface IAdminActions {
  createUser(data: UserData): void;
  editUser(id: string, data: UserData): void;
  deleteUser(id: string): void;
  changeUserRole(id: string, newRole: Role): void;
}

Passo C: implemente apenas o que for necessário.

class Viewer implements IViewerActions {
  viewUserProfile(id: string): UserProfile {
    console.log(`Fetching profile for user ${id}...`);
    // ... fetch and return profile
  }
}

Um administrador pode implementar várias interfaces conforme suas responsabilidades. Essa separação reduz recompilações desnecessárias e deixa claro quem possui cada capacidade.

2) Refatorando props inchadas do React com uniões discriminadas

Uniões discriminadas do TypeScript permitem contratos claros para variantes de componente, evitando combinações inválidas e simplificando o editor.

// GOOD: base props
type BaseCardProps = {
  title: string;
  onClick?: () => void;
};

// GOOD: variantes específicas
type ImageCardProps = BaseCardProps & {
  cardType: 'image';
  imageUrl: string;
  imageAltText: string;
};

type ArticleCardProps = BaseCardProps & {
  cardType: 'article';
  description: string;
  authorName: string;
  articleLink: string;
};

type CardProps = ImageCardProps | ArticleCardProps;

Com esse padrão, o editor de código aplica apenas combinações válidas de props e previne erros em tempo de compilação².

Auditar e aplicar ISP na sua equipe

Correções pontuais ajudam, mas incorporar o ISP às práticas da equipe entrega valor duradouro. Combine critérios de auditoria com verificações automatizadas para manter interfaces saudáveis.

Critérios claros de auditoria

Crie uma checklist para identificar violações de ISP durante code review. Sinais de alerta:

• Interfaces com muitos métodos (inspecione quando acima de cinco a sete métodos).
• Métodos vazios ou stubados em implementações.
• Nomes de interface vagos com termos como “Manager” ou “Handler”.
• Props de componentes com muitos campos opcionais.

Automatizando a aplicação

ESLint e regras customizadas capturam padrões diretos, como props grandes ou classes que deixam métodos sem implementação³. Assistentes de codificação por IA também ajudam a sinalizar cheiros de design quando solicitados a revisar interfaces e implementações⁴.

Combinar checagens automatizadas com revisões humanas é o ideal: ferramentas provêm consistência e velocidade; humanos capturam contexto e intenção de negócio. Interfaces menores também apoiam ciclos TDD mais rápidos porque são mais simples de mockar e testar⁵.

Use ambos: automação para verificações rotineiras e revisores para decisões de design nuançadas.

ISP e desenvolvimento assistido por IA

Interfaces claras ajudam ferramentas como modelos estilo GPT e assistentes de código a raciocinar sobre o código. Contratos pequenos e bem definidos reduzem ambiguidade e melhoram a qualidade das sugestões, refatorações automatizadas e documentação gerada por IA⁴.

Interfaces limpas atuam como um briefing preciso para humanos e máquinas. Essa clareza reduz suposições e resulta em mudanças assistidas por IA mais confiáveis.

Perguntas comuns sobre ISP

ISP significa que todo método precisa da sua própria interface?

Não. O objetivo não é criar interfaces de um método para tudo. Agrupe métodos que são sempre usados juntos pelo mesmo cliente. A meta é interfaces focadas e coesas, não fragmentação excessiva.

Como ISP difere do Princípio da Responsabilidade Única?

SRP se aplica a classes e diz que uma classe deve ter uma razão única para mudar. ISP aplica‑se a interfaces e diz que clientes não devem depender de métodos que não usam. É possível seguir SRP e ainda violar ISP se uma classe implementar uma interface gorda.

Quando é aceitável ignorar o ISP?

Quando você não pode mudar a interface — bibliotecas de terceiros ou APIs legadas — ou quando todo cliente realmente precisa de todos os métodos, uma interface maior pode ser coerente e aceitável.

Checklist rápido de refatoração

• Identifique papéis e clientes para cada interface.
• Divida interfaces grandes em contratos específicos por papel.
• Use uniões discriminadas do TypeScript para variantes de props de componentes².
• Adicione regras de lint para sinalizar interfaces ou props oversized³.
• Combine verificações automatizadas com revisão de código para decisões nuançadas.

Três perguntas e respostas concisas

Q: Como identificar rapidamente uma violação de ISP?

A: Procure por interfaces com muitos métodos não relacionados, classes com implementações vazias ou componentes com dezenas de props opcionais. Esses são sinais fortes de que um contrato deve ser dividido.

Q: Qual a forma mais rápida de corrigir uma "interface gorda"?

A: Identifique papéis de clientes distintos, crie interfaces específicas por papel e atualize implementações para implementar só o que precisam. Faça a mudança de forma incremental para reduzir risco.

Q: Como prevenir regressões de ISP em uma base de código em crescimento?

A: Adicione regras de lint e verificações em CI para detectar interfaces oversized e mantenha uma checklist de revisão para design de interfaces. Combine automação com auditorias manuais periódicas.

No Clean Code Guy, ajudamos equipes a aplicar princípios como o ISP para construir bases de código sustentáveis e prontas para IA. Obtenha uma auditoria gratuita da sua base de código para encontrar problemas ocultos e melhorar a manutenibilidade a longo prazo.