10. ISP: Princípio da Segregação de Interface
Não dependa do que você não usa.
Resumo
- Vários usuários usam operações diferentes de uma classe OPS. User1 usa só op1, mas depende de op2 e op3.
- Em linguagem estática, mudar op2 força recompilar e reimplantar User1 sem motivo.
- Solução: segregar interfaces por cliente (U1Ops, U2Ops…). OPS implementa todas.
- Linguagens dinâmicas sofrem menos no código, mas a lição é arquitetural.
- Arquitetura: depender de módulos com bagagem extra traz problemas inesperados (ex.: framework → banco).
Perguntas-chave
responda de cabeça, depois abraQual o problema de depender de uma interface gorda?
Mudanças em partes não usadas forçam recompilação, reimplantação e trazem riscos.
ISP é só de linguagens estáticas?
O efeito de recompilação é. A lição geral, não depender do desnecessário, vale para qualquer arquitetura.
Exemplo arquitetural de ISP?
Sistema S depende do framework F, que depende do banco D. Falha em recurso de D que S nem usa derruba S.
Exercícios de fixação
0/5 respondidas1.
User1 usa apenas
op1 da classe OPS, que também tem op2 e op3. Em Java, uma mudança em op2 causa:2.
Qual a solução proposta pelo ISP para o caso OPS?
3.
Um sistema S usa o framework F, que depende do banco D. Um recurso de D que S não usa falha e derruba S. Que princípio esse cenário ilustra?
4.
Por que linguagens dinâmicas como Ruby e Python sofrem menos com o problema do ISP no código?
5.
A frase que melhor resume o ISP é: