32. Frameworks são Detalhes
Casamento assimétrico. Use, não se case.
Resumo
- Autores de frameworks resolvem os problemas deles, não os seus.
- Casamento assimétrico: você se compromete totalmente; o autor não se compromete com você.
- Riscos: framework viola Regra da Dependência, ajuda no começo e atrapalha depois, evolui contra você, surge outro melhor.
- Solução: não se case. Mantenha o framework atrás de fronteiras; trate-o como plugin. Spring injeta em Main, não em entidades.
- Exceções aceitas: biblioteca padrão, STL. Decida conscientemente quando casar.
Perguntas-chave
responda de cabeça, depois abraO que é o casamento assimétrico?
Você se amarra ao framework (herda classes, segue convenções); o autor não tem compromisso algum com você.
Como usar Spring sem casar?
Usar a injeção de dependência só em Main/borda; nada de anotações @Autowired nas entidades e casos de uso.
Quando casar com um framework é aceitável?
Com bibliotecas fundamentais e estáveis (ex.: STL, biblioteca padrão), por decisão consciente.
Exercícios de fixação
0/5 respondidas1.
Uma entidade de negócio herda de
ActiveRecord::Base. Qual o problema?2.
O que é o "casamento assimétrico" com frameworks?
3.
Como usar Spring de forma limpa?
4.
Qual risco de frameworks não é citado no capítulo?
5.
Qual atitude é recomendada diante de frameworks?