Um padrão nomeia uma colaboração útil
Considere a regra de matrícula com três meios de confirmação. Strategy separa um comportamento que varia e permite escolher a estratégia adequada. Adapter converte a interface de um fornecedor externo para o contrato usado no domínio. Factory centraliza a decisão de qual implementação criar quando essa escolha precisa ficar num lugar só. Dependency Injection passa o colaborador pronto para quem usa.
Não são quatro nomes para “usar interface”. Strategy organiza variações intercambiáveis; Adapter protege o restante do sistema de uma API incompatível; Factory organiza criação; injeção muda quem monta a dependência. Às vezes new é suficiente. Crie uma abstração quando existe uma variação, integração ou responsabilidade que justifica o limite.
Observe o fluxo antes de escolher o padrão
Escreva primeiro a regra e identifique o que realmente muda. Se dois provedores têm o mesmo contrato, Strategy pode fazer sentido. Se a API de um provedor tem nomes ou formatos incompatíveis, um Adapter pode traduzi-la. Uma Factory só agrega valor se a lógica de criação está se repetindo ou precisa ser centralizada.
Vídeo previsto para 20/10/2026. Este apoio já prepara os conceitos; o vídeo será adicionado quando estiver público.
Recupere: qual problema cada padrão resolve, e qual pode continuar sendo um simples construtor?
Pratique com /aprender
/aprender Dê-me três pequenos problemas de uma aplicação de matrículas: escolher um cálculo de desconto, integrar um provedor com API diferente e decidir qual implementação criar. Apresente um de cada vez, peça minha previsão do padrão e critique se alguma abstração é desnecessária.
