Quem não conhece o princípio, KISS pode ler meu post sobre o assunto.
Tenho visto cada vez pessoas fazendo perguntas, em fóruns e grupos de discussão, sobre como utilizar design patterns, como aplicar conceitos de OO em uma aplicação .Net. Isto é muito bom, sinal de que a comunidade de desenvolvedores .Net está amadurecendo.
O que me preocupa são as respostas a este tipo de pergunta. Cada um que responde manda uma lista de sugestão de patterns, application blocks, frameworks. Eu fico assustado, metade destes nomes eu nem sei para que serve. O camarada diz que vai fazer uma aplicação WinForms, alguém já manda ele estudar o CAB (Composite Application Block).
Um dos mais famosos economistas do mundo, Milton Friedman, disse: não existe almoço grátis. Ou seja nada é de graça, sempre existe um custo e alguém está pagando. No design de software também não existe mágica, toda solução para um problema tem custos e benefícios. Projetar software, portanto, é a arte de definir a(s) solução(ões) com a melhor relação custo/benefício para atender todas as necessidades levantadas.
Portanto ao escolher um design pattern ou um application block para sua solução é necessário ter conhecimento dos custos disto. E com certeza eles existem. Por exemplo, utilizando o dependency injection (o pattern da moda) você está diminuindo o acoplamento da sua aplicação, mas está aumentando complexidade. Você terá arquivos XML para configurar, etc.
Um outro exemplo, o CAB. Ele é poderoso, possibilita criar UI complexas, divididas por módulos, centraliza o controle de eventos, entre outras coisas. Se você precisa de toda esta complexidade, ótimo utilize o CAB e evite muitas horas de desenvolvimento, teste e manutenção. O problema é que 90% das aplicações em WinForms precisa algo bem mais simples, se este for o seu caso, você estará adicionando complexidade desnecessária em sua solução aos insista em utilizar o CAB.
O ponto que quero frisar aqui é: não utilize um design pattern a não ser que ele resolva um problema da sua aplicação, não utilize um framework a não ser que ele se encaixe muito bem em suas necessidades. Mantenha as coisas simples e amanhã, quando você tiver que fazer manutenção, vai agradecer.
Bom trabalho e Keep It Simple, Stupid!