Você já viu Use Case Points, você já viu Function Points, agora não perca a mais nova opção: Design Pattern Points, mais uma nova métrica que não diz nada para seu sistema.
Essa onda de Design Patterns é engraçada. Essa discussão é prova de como as pessoas simplesmente não entendem as coisas. Quantos Design Patterns têm seu sistema? Vixe, só isso?
Pra você que é novo nesse mundinho Java (calma Eliziário), Design Patterns são receitas de bolo para resolver problemas. Os primeiros Patterns (ou Padrões) a serem catalogados foram aidna quando C++ era a única linguagem OO que era usada de verdade e Java era utilizado para fazer applets (por incrível que apreça, a Microsoft tinha até uma JVM). Então Patterns são receitas de bolo, Design Patterns são receitas de bolo para projeto de software, temos Padrões Arquiteturais, de Gerência, de Projeto (Project, não Design), etc. Padrões vão sobreviver a Java e não são nem novos nem exclusivos da plataforma.
Outro dia falamos aqui sobre como Padrões ajudam a falar um idioma comum. Você não imagina de quantos busy waits o mundo foi salvo por alguém ouvir falar em Observer. Patterns servem para isso: um catálogo de soluções que você pode usar e um vocabulário comum. Mas agora as pessoas se agarram aos tais padrões como se isso fosse gerantir a qualidade do projeto.
Vamos lá, o raciocínio é óbvio. Padrões são bons, logo muitos Padrões == muito bom. E nasce mais um sistema entupido de Observers que puxam uma Chain of Responsability passando três DTOs que são persistidos pelos DAOs numa sequência de Actions decoradas criadas por Factory Methods. Isso tudo para aquela funcionalidade de “Fale Conosco” do site. É, aquela que tem um formulário de três campos e manda um e-mail para webmaster@seila.com.br . Vamos e vanhamos: é mais fácil usar do que entender. Questionar dá muito trabalho, usa e cala a boca.
Um exemplo clássico é o DTO. Você usa DTOs no seu sistema? VOs? TOs? Por que?
No sistema em que tenho trabalhado recentemente existe real encessidade de DTOs. Foi a única vez que vi isso e semrpe trabalhei com sistemas com um grau de distribuição alto. Este é especial, os clientes estão em outras máquinas e precisam de um bando de objetos do servidor.
Mas a grande enomre gigante maioria das pessoas usa DTOs nos seus ssitemas sem a menor utilidade. Pra que? Para ganhar mais pontos nesta métrica. Para seguir blueprints Java EE.
Claro que isso acarreta num aumento enorme de complexidade, já que você tem que mantêr duas hierarquias de objetos diferentes. Claro que issod eixa o sistema mais lento com tanta cópia de valor/referência inútil. Mas e daí? Ano que vem me certifico em Design Pattern Points.
Comentei em tom de brincadeira com meu gerente e ele adorou. Já entrará em nossa próxima proposta de software para o governo.
Olha, não tinha visto isso no seu blog, to acompanhdo a algum tempo já, essa discussão que voce postou quem começou foi eu :d
eu era meio bitolado nessa historia de patterns mesmo, tenho que admitir, fiquei viciado no site da SUN e fazia 10 classes para imprimir um hello :D
aehuaheuhauehuaehuaheuhauehuaehuaheuhauehuae
acompanhando a discussão aqui de novo vi como evolui em poucos meses…. me dá até vergonha de ler o que escrevi
aehuaehuaheuhauehuaheuahuehuaehuaheu
mas é isso aí, teu blog tá muito bom! vlw!