Desenvolvimento de sistemas geralmente são repletos de discussões… longas e cansativas discussões relativas à arquitetura e design. Geralmente é no meio dessas discussões que se pode identificar um tipo peculiar de programador: o pattern-addicted developer.
Esse tipo de programador, geralmente tem um bom conhecimento técnico, domina a linguagem e os frameworks que estão sendo utilizados. Mas tem um vício perigoso: a necessidade insaciável em aplicar todos os design patterns que ele conhece em todos os projetos. Para ele, quanto mais classes e interfaces, melhor. Nas mãos de um pattern addicted, um cadastro simples pode ser tornar num monstrinho de n camadas, com milhares de Facades, Session Layers, DTO’s, VO’s, Factories, DAO’s, Adapters, Mediators e Business Delegates. Para o pattern-addicted, código fonte bem escrito, é complexo. Tão complexo, que poderá ser manutenido apenas por ele mesmo.
A simplicidade na programação, é um assunto que vem montivando muita gente. Rico Mariani (Microsoft), fala sobre simplicidade e performance:
I hardly think that one can make any conclusions about which vendor has the edge in performance from my article on Performance Tidbits. If I was to summarize my advice in that blog in a few words it would be “don’t use OOP features that you don’t need.”
This is not to say that you should shun virtual functions, inheritance, or other features of modern programming languages. Far from it, often they not only add clarity and maintainability they also improve performance. But, as often, I find that people have written their code in some elaborate way when a much simpler model would have been equally servicable and more performant. Whatever programming religion you may have I think you’ll agree that more complex language abstractions do not inherently help your design — rather each more sophisticated feature starts at a net negative and must somehow earn its way to positiveness with benefits such as clarity, ease of maintenance, performance, and so forth.
From Rico Mariani’s Performance Tidbits
Código fonte complexo, é um forte candidato a refactoring. Simplicidade é tudo. Não vamos utilizar design patterns sem necessidade. Faça a coisa mais simples possível que possa funcionar. Não pense em problemas que você ainda não tem. Se foque no que precisa ser feito agora. Torne o YAGNI uma filosifia de trabalho. O pessoal do 37signals, já falou muito a respeito disso:
Keep your code as simple as possible. You’d think that twice as much code would make your software only twice as complex. But actually, each time you increase the amount of code, your software grows exponentially more complicated. Each minor addition, each change, each interdependency, and each preference has a cascading effect. Keep adding code recklessly and, before you know it, you’ll have created the dreaded Big Ball of Mud.
Não há nada de errado na aplicação dos design patterns catalogados pelo GoF – Design Patterns: Elements of Reusable Object-Oriented Software ou nos Blue Prints da SUN. Mas não crie problemas, apenas para poder utilizá-los.
Não vejo nenhuma vantagem em investir muito tempo tentando resolver algo, que um dia talvez, poderá vir a acontecer. Implementar soluções, na tentativa de resolver problemas que ainda não existem, não fazem muito sentido para mim. Todos os requisitos não precisam ser implementadas agora. Ao invés disso, acho mais inteligente fazer esforços para manter componentes desacoplados, permitindo que o sistema cresça interativamente de forma sustentável, à medida que novas funcionalidades vão sendo inseridas. As vezes, é fundamental saber o que deve se descartado.
The “secret” to good software design wasn’t in knowing what to put into the code; it was in knowing what to leave OUT! It was in recognizing where the hard-spots and soft-spots were, and knowing where to leave space/room rather than trying to cram in more design.
Brad Appleton
Em se tratando de software, quanto menos, melhor.
Tags: patterns, programação
