Livro Design Patterns: e se houvesse uma segunda edição?

Recentemente, numa entrevista ao Gang of Four, foi revelada a intenção de uma nova edição do mais que conhecido livro Design Patterns:
http://www.informit.com/articles/article.aspx?p=1404056

Em uma excelente e curta entrevista, os autores falam de diversos tópicos, como a necessidade de design patterns em linguagens funcionais e dinâmicas, alguns patterns que viraram smells em grande parte dos casos (anti patterns) como o singleton, injeção de dependências como pattern e muito mais. Leitura recomendada!

abraços!

Olá

Tenho para mim que o livro da gang dos 4 é um bom livro mas a pressão pelo uso de design patterns foi ruim para os programadores em geral.

Explico:

Padrões deveriam ser uma segunda ou terceira preocupação do programador. Ele deveria se concentrar em resolver o problema da forma que conseguisse. No futuro ao refatorar, caso reconhecesse algum padrão aí sim alterava o código.

Mas não foi isto que vi muitas vezes. Os caras achavam bonitinho programar por padrões.

Ora, foi neste mundo fértil de beócios que surgiu aquele terrível livro da Sun dos Core Design Patterns. Os programadores eram então incentivados a fazer do modo complexo coisas que poderiam ser mais simples.

Por algumas discussões aqui no GUJ, temo que esteja acontecendo algo semelhante com DDD. As vezes leio alguns posts tão complexos que fico com saudades do tempo em que a gente se concentrava no problema a resolver sem precisar satisfazer o colega que acha mais bonitinho assim ou assado.

Fiquem tranquilos, não estou tendo ataques de duct-tape programmer by Joel Spolsky. Apenas acho que design patterns deve ser usado por programadores experientes que reconhecem um padrão ao olhar a solução codificada ao invés de ser usado só para o programador falar difícil para o colega que usou XPTO ou KYMZ.

Seria interessante uma segunda edição baseada em outras linguagens. Mas deveria vir com um alerta: A gang dos 4 adverte, usar design patterns em excesso pode causar embruculhamento (*) do seu código.

(*) Substitua embruculhamento por uma palavra mais feia se conseguir

[]s
Luca

Muito interessante a entrevista.

Será que alguém poderia indicar alguma situação onde Singleton ainda seria útil nos dias de hoje?

Forum Spammer Membro desde: 22/03/2005 20:57:48 Mensagens: 3177 Offline

tnaires wrote:Muito interessante a entrevista.

Será que alguém poderia indicar alguma situação onde Singleton ainda seria útil nos dias de hoje?

Em várias situações. Mas normalmente nas que se vivem no mundo EE (liás a especificação meio que proibe isso)

Singleton é util e está em vários lugares da API padrão.

Dizer que ha um problema com o singleton é não entender o que um padrão é. O problema não é com o sigleton, é com a educação OO das pessoas. A maior parte usa um singleton (porque é o padrão que aprendeu) para resolver coisas que seriam corretamente resolvidas com um outro padrão. O erro é do programador e do ensino, não do padrão ou de quem o identificou.

Padrões são para OO o que receitas são para a culinária, mas ao contrário. Quando vc começa na culinária começa seguindo receitas e só depois vc evolui para o estado em que pode simplesmente fazer. Vc entendeu as regras inerentes às receitas e vc as aplica abstractamente. Os padrões é ao contrário. VC começa por não os usar, mas vc segue os principios de OO (os que não os seguem têm problemas mais graves ). Ao usar os principios abstratamente durante um tempo vc identifica padrões.
O pulo do gato é que os padrões se podem ensinar mesmo a quem não segues os principios abstratamente e a pessoa pode programar bem usando padrões mesmo sem conhecer muito OO.

O problema não são os padrões. O problema é a fraca cultura dos programadores que não os entendem. Confundem tudo, é um caos. Coisas como dizer que pode haver mais do que uma instancia de um singleton ou que MVC é separação em camadas são exemplos da pouca e fraca cultura de padrões.

Usar padrões e programar padrões sim é uma vantagem. Quem não entende isto é porque não os usa direito ou nunca viu alguem usar direito. ... ou simplesmente é preguiçoso.

Já tenho ouvido absurdos de fazer qualquer codigoa ad hoc e depois refactorar. Isso gera um custo imenso, porque a primeira coisa que o cara faz é gamb. Refactorar gamb é impossivel.

Existe até um livro "refactorando para patterns". Se eu vou refactorar para patterns isso significa que o programa escrito com patterns é que é o melhor. portanto, se eu programar com patterns desde o inicio não preciso refactorar.

Refactorar virou pipula mágica para desculpar a asnceira, a falta de conhecimento e a gamb. Senhores, refactorar é caro! e quanto mais gamb é, mais caro fica.

Aprender a programar usando patterns é aprender a programar usando meta-OO. um nivel acima. claro, se quase ninguem sabe OO não se pode esperar que saiba patterns , mas dizer que patterns é ruim é simplesmente absurdo e um desfavor à comunidade OO (seja em que linguagem for)

Será que alguém poderia indicar alguma situação onde Singleton ainda seria útil nos dias de hoje?

Até nesses casos que porventura existam, singleton não se justifica, IMHO.

Até não vejo problema em usar uma instância só pra fazer alguma coisa, a parte ruim é obrigar, como o pattern faz.

This message was edited 1 time. Last update was at 27/10/2009 18:08:19

Paulo, muito bom, obrigado por compartilhar.

tnaires, o singleton foi muito usado no passado, porém houve uma onde de "não usar" singleton... coitado dele, de um dia para o outro foi escurraçado. Ele era muito bom pelo fato de criar uma instancia unica, mas hoje em dias com os processadores mais inteligentes somados a evolução da própria vm instanciar objetos e coleta-los nem é mais tão preocupante. Vejo assim não haver uma necessidade de singleton. Lembrando que há uma proposta pro EJB 3.1 de haver uma anotação @Singleton.

Uma discução que acompanhei há algum tempo foi sobre logging... em ambientes j2ee se você usar sua classe de logger como static você não consegue trabalhar bem com os repository selectors, onde criando como instancia normal você consegue usá-los.

Luca, concordo mesmo contigo sem adicionar ou remover alguma palavra do seu post. Excelente.

Abraços

Como foi mencionado, concordo totalmente com o Luca!!!. E a Kathy Sierra deveria escrever o novo livro, aí seria um catalogo bom de ler!!

Sobre o singleton especificamente: o problema não é o fato de ter ou não uma instância única da minha classe. O problema é que as demais classes que usam esse meu objeto único são obrigadas a saber que aquilo é um singleton (normalmente através do famigerado getInstance estático).

A evolução do singleton hoje, na linha da separação de responsabilidades, é usar inversão de controle e injeção de dependencias. Minha classe que precisa daquela outra de instancia unica, ao inves de chamar o getInstance, recebe uma dependencias. E o container resolve se a instancia a ser injetada deve ser unica ou não.

Compare qual código deixa as duas classes mais desacopladas:

ou:

No fim, singleton hoje deixou de ser Design Pattern de código e passou a ser configuração de escopo em containers IoC.

Sergio Lopes wrote:Sobre o singleton especificamente: (...)

Seu exemplo mostra com toda a clareza porque é difícil escrever testes para singletons.

JavaGuru Membro desde: 04/04/2007 19:21:36 Mensagens: 251 Offline

De uma coisa tenho que concordar com o Luca, quando chegamos e conhecemos outras linguagens e comunidades, percebemos o quanto o Java se torna mais complexo com a tal caracteristica de adicionar Isso e Mais aquilo e Aquilo outro só para ficar, digamos, "bonitinho". Nisso vejo que, por fora, Ruby, Python e outras vem ganhando terreno e matando o Java e sua extrema complexidade. Lamentável.

Olá

javamaniaco wrote:De uma coisa tenho que concordar com o Luca, quando chegamos e conhecemos outras linguagens e comunidades, percebemos o quanto o Java se torna mais complexo com a tal caracteristica de adicionar Isso e Mais aquilo e Aquilo outro só para ficar, digamos, "bonitinho". Nisso vejo que, por fora, Ruby, Python e outras vem ganhando terreno e matando o Java e sua extrema complexidade. Lamentável.

Você captou justamente o que eu quiz dizer. A complexidade inibe o iniciante. Vamos programar, resolver problemas, aprender o negócio, saber usar TDD. Deixem o código bonitinho para lá enquanto aprende. Com tempo a gente melhora. E aí então naturalmente usará alguns padrões.

Muito melhor do que se preocupar em escrever código baseado em padrões é se habituar a fazer revisão de código. Se você não costuma fazer as partes mais dificeis usando programação em par, pelo menos reserve alguns momentos do seu dia para sentar com outros programadores para rever os códigos deles e principalmente para que outros revejam seu código. Convença seu chefe de que isto não é perda de tempo. Vai aprender bem mais rápido e evitar levar adiante código que nem você que fez consegue explicar para o colega.

E nunca esquecer que a gente programa para resolver negócio.

[]s
Luca

This message was edited 1 time. Last update was at 27/10/2009 19:56:29

Sergio Lopes wrote: (...) o container resolve se a instancia a ser injetada deve ser unica ou não.

Concordo com o Sergio sobre usar DI invés de codificar seu Singleton,. diminuindo o acoplamento entre dependencias. Mas notem que a MOTIVAÇÃO que é algo fundamental na execução de qualquer pattern ainda existe no caso do Singleton, a diferença é que não é você que o codifica, é algum framework ou biblioteca.

Logo o Singleton, ainda hoje, pode e deve ser utilizado, a diferença é que não tem que codifica-lo em seu projeto já que o fizeram por você... apenas anote ou configure seu framework favorito

Importante no singleton é nao ficar chamando um metodo estatico getInstance como o Sergio mostrou: voce fica super acoplado e é dificilimo de testar (passar mocks). Assim como factory methods, é importante isolar esses patterns criacionais dependente de metodos estaticos, fazendo com que voce recebe a referencia no construtor: facilita bastante qualquer tipo de teste e diminui drasticamente o acoplamento.

Forum Spammer Membro desde: 22/03/2005 20:57:48 Mensagens: 3177 Offline

Acho que devo ter acessado o guj de um universo paralelo ... o que se passa com vcs ?

Desktop é uma classe singleton no JSE. Onde é que está escrito que ele é um singleton ? Cadê a assinatura souumsingleto.getsingleton ? Compare com Calendar.getInstance e Locale.getInstance que não são singleton.

Tente injetar Desktop numa classe. É muito simples com Guice, não tanto com Spring, mas e dai ? é possivel. é o que interessa.

confundir singleton dom DI ? mas que raios vcs estão pensando ? Singleton é um padrão criacional !
Vc se esquecem que DI usa factories. Alguem tem que criar os objetos para eles serem injetados !! em todos os motores de DI vc pode configurar essas factories. O ponto não é injetar, mas sim criar. Se a classe ñ é singleton várias instancias podem ser criadas mesmo com um motor de DI.

Singleton como acesso global é subsittuido por Registry.

@Singleton é a perpetuação da asneira. Não satisfeitos com a confusão do VO o povo da jcp adora meter lenha na fogueira. A culpa é do Spring que chama - erradamente - de singleton objetos que são na realidade shared object. E como o povo do Spring está na jcp... bom, já se viu.

Singletons reais são raros. Mas isso não invalida o padrão. O problema é o mau entendimento que as pessoas têm de padrões. Não só design patterns, mas de outros como Produtor-Consumir que é essencial em mensageria e concorrencia.

Castigar o singleton pelo mau uso que os programadores fazem dele é como castigar a tinta pelas palavras groseiras que se escrevem com ela. Ainda mais absurdo é culpar todos os padrões como um todo. É como se castigássemos o próprio alfabeto por permitir escrever palavras.

Vcs não estão dizendo coisa com coisa. Quem ler isso vai achar que padrões é uma porcaria. A mensagem a ser transmitida não é essa. É exatamente ao contrário. Foi depois que padrões foram introduzidos na API do java que ele ficou mais limpo. A API de collections é um otimo exemplo assim como a nova NIO2 usando Visitor para iterar arquivos. E já a NIO tinha melhorado usando uma versão de observer. E a JDBC que todo o mundo usa toda a hora é um excelente exemplo de Bridge.
O melhor e mais edgy de java é feito com aplicação de padrões!

Agora, o problema é: estudar padrões , aprender padrões, e usar padrões é dificil e complexo! Não é para qualquer um. Portanto:
1) padrões é otimo.
2) aprenda-os
3) aprenda-os direito!

Ha certas ocasiões em que dá tristeza ver o que se escreve de padrões ... frases do tipo "Fiz um façade para encapsular a chamada"

É como ver as pessoas falarem mal ou escreverem errado. Fere os ouvidos e corta o coração quando é um profissional dizendo.
O pior não as pessoas não saberem, é alguem dizer que aprender é inutil.

Bom falar que padrões são necessários por causa da austeridade da linguagem é ainda pior asneira. São padrões de OO , de design, de arquitetura , de segurança, etc... não são padrões de linguagem !! afinal o GOF era smalltalk e C++ e ainda é válido em java, C# , qq outra linguagem OO.

Que raios deu em vocês ?

JavaGuru Membro desde: 04/04/2007 19:21:36 Mensagens: 251 Offline

sergiotaborda wrote:

Castigar o singleton pelo mau uso que os programadores fazem dele é como castigar a tinta pelas palavras groseiras que se escrevem com ela. Ainda mais absurdo é culpar todos os padrões como um todo. É como se castigássemos o próprio alfabeto por permitir escrever palavras.

Que raios deu em vocês ?

Palavras bonitas mas como de um político. Você fala para poucos e logo poucos lhe escutam. Conheceu Rails? Viu Ruby? Quando colocamos a mão em situações como Ruby, Rails, questionamos o porque o Java ou outra louca linguagem que deseja seguir este método obscuro de desenvolvimento existe. Desde que comecei a aprender Java vi tantas palavras que posso colocar em um dicionário facilmente. Também vi quando comecei a trabalhar com isso que os projetos pequenos se tornam demorados. Seria falta de conhecimento decoreba dos padrões? Sei não, pra mim é coçar a orelha esquerda com a mão direita.
Ai vem um Rails da vida, mostra que, tudo que fiz poderia ser prático, divertido e nada confuso. Que A que programou, B entende, C entende e qualquer outras letras que colocar aqui, entende. Agora, tem projetos em Java que, graças a Deus, inventaram as IDE's, porque é a coisa mais louca que já vi, é um padrão X que passou a ser chamado de Y, porque antes era VO, depois virou "PÓ", rs. Ai fazem as maravilhosas packages com nomes de sei lá o que e dizem: há, isso é DDD. Putz, quantos anos levam para um iniciante aprender tudo isso? Quanto tempo terei que machucar minhas mãos para escrever "belamente"?
Eu digo uma coisa, levei nem 1 mês para entender Rails, em 2 meses estava em um projeto e até hoje já passei por 4 projetos em Rails, sendo um de porte médio. Mudei de equipe várias e várias vezes e cada linha escrita e reescrita eu compreendo. Se entrar no meio de um projeto Rails já sou produtivo. Se for em Java, só se der sorte. Sorte com a complexidade ou com metidos arrogantes que arrotam letras e padrões que nunca ouvi falar, mas que existem talvez para tornar o programador mais valioso.
Desculpe o desabafo gente, mas é que já vi tantas discussões de padrões e cada dia mais penso que sei menos. Já até falei em outro post que to quase mudando meu nick para rubymaniaco.

Notícias, artigos e o maior fórum brasileiro sobre Java