11. DIP: Princípio da Inversão de Dependência
Dependa de abstrações, não de concreções voláteis.
Resumo
- Código flexível: dependências de código-fonte apontam para abstrações, não implementações.
- Exceção: concreções estáveis (ex.:
String, libs do SO). Foco: elementos voláteis. - Regras: não referir classes concretas voláteis; não derivar delas; não sobrescrever funções concretas; não citar nome concreto volátil.
- Criar objetos exige concreto → Abstract Factory. Fronteira divide lado abstrato e lado concreto.
- Algumas violações são inevitáveis: ficam em main (componente concreto). Base da Regra da Dependência.
Perguntas-chave
responda de cabeça, depois abraDepender de String viola o DIP?
Não. String é concreta, mas muito estável. O DIP mira concreções voláteis.
Como criar objetos sem depender do concreto?
Abstract Factory: o lado abstrato chama a interface da fábrica; o lado concreto a implementa.
Onde ficam as violações inevitáveis de DIP?
Em componentes concretos como Main, que instanciam e conectam as implementações.
Exercícios de fixação
0/5 respondidas1.
Qual destas dependências é aceitável segundo o DIP?
2.
Qual padrão resolve a necessidade de criar objetos concretos sem que o código abstrato dependa deles?
3.
Por que interfaces devem ser menos voláteis que implementações?
4.
Onde devem ficar as violações de DIP que não se pode evitar?
5.
Qual afirmação não é uma prática do DIP?