Boas práticas e padrões · Princípios SOLID · 4 min de leitura
I — Princípio da segregação de interfaces (ISP)
Nenhum cliente deve depender de métodos que não usa: prefira várias interfaces pequenas a uma interface gorda.
Arraste para o lado para ver o diagrama inteiro.
O problema
Uma interface com quinze métodos obriga implementações a escrever métodos vazios ou que lançam exceção, e acopla clientes a mudanças que não lhes dizem respeito (recompilar, re-testar, mocks enormes).
A solução
Divida por papel (role interfaces). Uma classe pode implementar várias; cada cliente pede apenas a que usa. Em Kotlin e TypeScript, interfaces pequenas também tornam os fakes de teste triviais.
No código: antes e depois
interface Dispositivo {
imprimir(doc: Doc): void;
digitalizar(): Imagem;
enviarFax(numero: string, doc: Doc): void;
}
class ImpressoraSimples implements Dispositivo {
imprimir(doc: Doc) { /* ok */ }
digitalizar(): Imagem { throw new Error('não suportado'); }
enviarFax() { throw new Error('não suportado'); }
}interface Impressora { imprimir(doc: Doc): void }
interface Scanner { digitalizar(): Imagem }
class ImpressoraSimples implements Impressora {
imprimir(doc: Doc) { /* ok */ }
}
class Multifuncional implements Impressora, Scanner {
imprimir(doc: Doc) { /* ... */ }
digitalizar(): Imagem { /* ... */ return new Imagem(); }
}
// a tela de impressão depende só de Impressora
function telaImpressao(dev: Impressora) { /* ... */ }Nenhuma classe precisa fingir que sabe fazer algo, e o teste da tela usa um fake de um método só.
Em resumo
- Interfaces por papel, pequenas e coesas.
- Uma classe pode implementar várias interfaces.
- Fakes de teste ficam com 1 ou 2 métodos.
- Métodos "não suportado" indicam interface gorda.