Como você diz, os eventos são uma ótima ferramenta para reduzir o acoplamento entre classes; portanto, embora possa envolver a criação de código adicional em alguns idiomas sem suporte interno para eventos, reduz a complexidade da imagem geral.
Os eventos são sem dúvida uma das ferramentas mais importantes no OO (de acordo com Alan Kay - os objetos se comunicam enviando e recebendo mensagens ). Se você usa um idioma que possui suporte interno para eventos ou trata funções como cidadãos de primeira classe, usá-los não é fácil.
Mesmo em idiomas sem suporte interno, a quantidade de clichê para algo como o padrão Observer é bastante mínima. Você pode encontrar uma biblioteca de eventos genéricos decente em algum lugar que possa ser usado em todos os seus aplicativos para minimizar o clichê. (Um agregador de eventos genérico ou mediador de eventos é útil em quase qualquer tipo de aplicativo).
Vale a pena em um aplicativo pequeno? Eu diria que sim definitivamente .
- Manter as classes dissociadas entre si mantém o gráfico de dependência de classe limpo.
- Classes sem nenhuma dependência concreta podem ser testadas isoladamente, sem consideração por outras classes nos testes.
- Classes sem nenhuma dependência concreta exigem menos testes de unidade para uma cobertura completa.
Se você está pensando "Ah, mas é realmente apenas um aplicativo muito pequeno, isso não importa muito" , considere:
- Às vezes, aplicativos pequenos acabam sendo combinados com aplicativos maiores posteriormente.
- É provável que aplicativos pequenos incluam pelo menos alguma lógica ou componentes que possam precisar ser reutilizados posteriormente em outros aplicativos.
- Os requisitos para aplicativos pequenos podem mudar, solicitando a necessidade de refatorar, o que é mais fácil quando o código existente é dissociado.
- Recursos adicionais podem ser adicionados posteriormente, solicitando a necessidade de estender o código existente, o que também é muito mais fácil quando o código existente já está dissociado.
- Código fracamente acoplado geralmente não leva muito mais tempo para escrever do que código fortemente acoplado; mas o código fortemente acoplado leva muito mais tempo para refatorar e testar do que o código pouco acoplado.
Em geral, o tamanho de um aplicativo não deve ser um fator decisivo para manter as classes fracamente acopladas; Os princípios do SOLID não são apenas para grandes aplicativos, são aplicáveis a software e bases de código em qualquer escala.
De fato, o tempo economizado no teste unitário de suas classes de acoplamento fraco isoladamente deve contrabalançar qualquer tempo adicional gasto na dissociação dessas classes.