Padrões de design são ferramentas. Como as ferramentas, existem duas maneiras de usá-las: a maneira correta e a maneira incorreta. Por exemplo, se eu lhe dar uma chave de fenda e um prego, e pedir-lhe para se juntar dois pedaços de madeira juntos, você deve me pedir um martelo. Martelos são usados para pregos, enquanto chaves de fenda são usadas para parafusos.
Com muita frequência, um padrão de design é anunciado como o Único Caminho Verdadeiro, que geralmente é verdadeiro apenas quando surgem problemas específicos. Os desenvolvedores juniores geralmente são como crianças quando encontram algo novo para brincar; eles querem aplicar esse padrão de design a tudo . E não há nada de errado com isso, desde que eles aprendam que o Padrão A se aplica ao Problema B e o Padrão C se aplica ao Problema D. Assim como você não usa uma chave de fenda para pregar pregos, você não usa uma determinada padrão apenas porque existe; você usa o padrão porque é a melhor ferramenta (conhecida) para o trabalho.
O outro lado dos padrões são anti-padrões. Coisas que provaram ser repetidas vezes ruins, geralmente em termos de tempo de execução ou memória. No entanto, padrões e antipadrões não são bons para o desenvolvedor que não entende por que eles existem. Os desenvolvedores gostam de pensar que o que estão fazendo é novo e inventivo, mas na maioria das vezes não. Provavelmente já foi pensado antes. As pessoas antes deles criaram os padrões por causa da experiência.
É claro que os desenvolvedores juniores geralmente parecem ter novas maneiras de fazer coisas antigas, e às vezes essas maneiras são melhores. No entanto, muitas vezes acaba sendo um caso do efeito Dunning-Kruger; o desenvolvedor sabe o suficiente para criar um programa funcional, mas não entende suas próprias limitações. A única maneira de superar isso parece ser através da experiência, tanto positiva quanto negativa. Eles ignoram os padrões porque se consideram superiores, mas não sabem que, na realidade, 10.000 desenvolvedores já usaram um design específico e o descartaram porque era realmente ruim.
O Agile é a favor de "fazer as coisas de maneira responsiva" no que diz respeito ao rápido ajuste à evolução das necessidades do cliente. Não favorece os padrões de design nem os despreza. Se um padrão é o método mais rápido e confiável, o desenvolvedor deve usá-lo. Se um padrão em particular custaria mais tempo do que simplesmente "fazê-lo", é provável que usar algo que não seja um padrão (supondo, é claro, que o desempenho não seja severamente degradado, etc.). Se nenhum padrão conhecido puder ser encontrado, é preferível criar um design próprio do que dizer ao cliente "não". Clientes, especialmente clientes pagantes, geralmente têm razão.
Qualquer um que afirme que os padrões são o Caminho, ou que os padrões sejam o Dilema da Existência, está errado. Padrões são ferramentas, destinadas a serem aplicadas a situações específicas e têm graus variados de sucesso com base nas circunstâncias. Essa é uma verdade, que não depende de você escolher o MVC ou não, se você usa objetos de transferência de dados ou não, etc. O que importa é implementar código em um período de tempo razoavelmente curto, com desempenho razoável para os usuários, e é razoavelmente livre de erros lógicos.
Normalmente , os padrões permitirão uma forma coerente de design e terão um desempenho melhor do que ignorar todos os padrões em favor de escrever idéias 100% originais, mas você não poderá evitar todos os padrões. Por exemplo, se y = x + 5, você realmente escreverá y = x + (5 * 3 + 15/3) / 4, apenas para evitar o padrão de escrever x + 5? Não, você não é. Você vai escrever y = x + 5 e seguir para o próximo problema.
As pessoas usam padrões todos os dias, e tudo bem . O que mais importa é ter um código que seja logicamente funcional, que raramente trava e seja fácil de usar. Nada mais importa mais do que isso.