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

What is classpath? Membro desde: 05/11/2009 11:46:18 Mensagens: 8 Offline

"O Design é sempre a intenção da Arquitetura"

Singletons ou não-singletons

Para o Spring, todos os beans são singletons, ou seja, só existe uma instância de cada um deles para aquela instância do framework.Algumas vezes, os nossos objetos têm dependências que não podem ser singletons, ou seja, cada bean precisa de uma instância própria de sua dependência.Para que o Spring trate um objeto não-singleton, o atributo "singleton" do nó<bean> deve estar com o valor "false".

This message was edited 3 times. Last update was at 06/11/2009 16:51:23

mochuara wrote:

victorwss wrote:
Penso que a mesma coisa pode acabar ocorrendo com os design patterns de hoje. Alguns tornar-se-ão características tão intrínsecas e enraizadas nas linguagens do futuro que muitas vezes nem serão percebidas como design patterns (Iterator, Strategy, Observer e MVC são bons candidatos).

Scala e Clojure que são linguagens bombando HOJE tem mecanismo de concorrencia enbutido na linguagem, Clojure vai além e conta ainda com controle transacional (UnitOfWork) e vc me diz que a linguagem do futuro vai conter Strategy e Observer??

Releia o que eu escrevi.

O goto por exemplo, continua existindo firme, forte, frequente e feliz nas profundezas dos sistemas e das linguagens mais modernas de hoje em dia, mas ele está escondido debaixo de tantas camadas de abstração que você não o vê, não mais o utiliza diretamente, mas isto não significa que ele não exista. O mesmo está acontecendo com o Strategy, Observer e Iterator.

No javafx, é bem interessante como é que o Observer foi absorvido pela linguagem em si na forma de triggers. Clojure também é um exemplo interessante de como as linguagens estão evoluindo.

Mas, há uma grande diferença entre Strategy, Observer, Iterator e goto. O goto quando utilizado diretamente pelo prograador é em 99,9% dos casos algo extremamente ruim que vai trazer muitos mais problemas do que benefícios. O Strategy, Observer e Iterator nas linguagens mais tradicionais de hoje (Java, C++, C#, smalltalk) decididamente não são o mesmo caso. Em linguagens mais avançadas como Clojure, JavaFX e Scala, o uso direto deles começa a se tornar um anti-pattern, mas acho que ainda não ao ponto que o goto tinha se tornado. Por outro lado o Singleton, já sofreu tanta entropia que está em situação cada vez mais semelhante ao goto: usá-lo diretamente é em 98% dos casos um tiro no pé, mas isso não significa que ele deixará de existir ou tornar-se-á deprecated, nem mesmo com o goto isto ocorreu. O seu uso direto é que poderá se tornar cada vez mais deprecated.

Bem, estou inventando agora: Poderíamos chamar de entropia a característica que uma determinada técnica ou padrão de programação tem que a deixa cada vez menos vantajosa e mais problemática quando usada diretamente a medida que cresce o nível de abstração. O goto por exemplo tem uma entropia altíssima, é vantajoso apenas nas camadas mais inferiores e menos abstraídas de linguagem de montagem, linguagens de máquina e bytecodes. O Singleton também já sofreu bastante entropia e não é mais vantajoso nas linguagens de hoje. O Iterator, Observer, Strategy e MVC já tem alguma entropia significativa também, mas ainda estão longe do ponto aonde o Singleton e o goto chegaram.

Algumas técnicas que surgem tendem a ganhar entropia de forma bem lenta, como por exemplo a modularização do código em procedimentos e funções. Esta técnica, apesar de bem antiga sofreu pouca entropia, mas isto não significa que um dia, em um futuro distante isso não vá ocorrer.

Minha conclusão empírica é que cada linguagem tem os seus padrões e técnicas apropriadas e específicas para o seu nível de abstração. Usar técnicas de níveis de abstração inferiores ao da linguagem tende a trazer gambiarras, problemas e bad smells. Usar técnicas de níveis de abstração superiores ao da linguagem tende a trazer complexidade e verbosidade. Quanto maior a diferença entre o nível de abstração da técnica e da linguagem, pior fica este problema.

jhacker wrote:"O Design é sempre a intenção da Arquitetura"

Singletons ou não-singletons

Para o Spring, todos os beans são singletons, ou seja, só existe uma instância de cada um deles para aquela instância do framework.Algumas vezes, os nossos objetos têm dependências que não podem ser singletons, ou seja, cada bean precisa de uma instância própria de sua dependência.Para que o Spring trate um objeto não-singleton, o atributo "singleton" do nó<bean> deve estar com o valor "false".
<bean id="dependencia" class="gerenciador.CursoDaoMemoria"singleton="false"/">

Isto já foi bastante discutido páginas atrás. É um erro de conceito. Embora sejam chamados erroneamente de singletons, não são singletons, são shared objects.

sergiotaborda wrote:Porque o MVC está associado a controles fisicos como teclado e mouse, as pessoas assumem que é um padrão arqutietural, mas não é. Para ser um padrão arquitetural ele teria que interferir com plataformas, andares (que eu chamei camadas neste texto) , nodos ou protocolos de comunicação. Ele não interfere com nada disto, logo não é um padrão de arquitetura. Embora existam muitos desavisados que o chamam assim.

um padrão realmente de arquitetura é o Cluster, por exemplo.

você demonstrou um exemplo, não necessariamente, ele, se resume a isto! sempre tenho visto o modelo MVC como padrão arquiteturial, me mostre uma referência que o dita que não o seja, que eu me convencerei!

a citação que mencionei, expôe também as vertentes de como o padrão MVC surgiu mesmo que com propósito limitado na época.
acho que temos que esclarecer ao pessoal agora algumas perguntas como:

1. Qual conceito de um padrão arquiteturial ? (motivado por referências)
2. Como um padrão arquiteturial pode ser classificado ?

entre outras perguntas interessantes que poderiamos incluir aqui, mas acho que isto pode ser melhor discutido em um novo tópico!

Luca wrote:Continuo com a mesma velha opinião de que os padrões devem ser usados quando reconhecidos ao invés de usados como demonstração de que o programador conhece padrões como já fui testemunha em mais de um projeto. E pior era ver os caras descrevendo o código usando padrões para complicar a linguagem dentro de uma equipe em que nem todos visualizam os padrões do mesmo jeito que o cara falava.

também concordo luca.

por exemplo, se você dispõe dos conceitos e princípios de O.O, você acaba usando um padrão sem saber. antigamente eu utilizava o template method sem saber.

a didática de aprender padrões de projeto, tratando-se de padrões da GoF ou GRASP neste caso, é justamente um ato de exercitar bons princípios de O.O, para velhos problemas conhecidos e que serão recorrentes ao longo da nossa atuação profissional, de forma que um determinado design descreva características de um ou mais padrões, resumindo-se em poucas palavras.

agora, se você souber fazer bom uso disto sem conhecer padrões e explicar como algo foi desenvolvido, você está no caminho mais do que certo, visto vez que, eles devem ser mencionados quando necessário, e isto é verdade porque nosso objetivo final é concluir um projeto atendendo a contento o mais simples possível de forma a minimizar custo, em prazo e que possibilite que a equipe se comunique em seu ritmo natural de forma a evoluir sem depender de padrões e catálogos como referências e normas em suas práticas atuais, e futuras pois podem acabar não sendo promissoras.

abusar do uso de padrões de projeto pode fazer mal a nossa saúde e a do projeto que estamos tratando!

faelcavalcanti wrote:

Luca wrote:Continuo com a mesma velha opinião de que os padrões devem ser usados quando reconhecidos ao invés de usados como demonstração de que o programador conhece padrões como já fui testemunha em mais de um projeto. E pior era ver os caras descrevendo o código usando padrões para complicar a linguagem dentro de uma equipe em que nem todos visualizam os padrões do mesmo jeito que o cara falava.

também concordo luca.

por exemplo, se você dispõe dos conceitos e princípios de O.O, você acaba usando um padrão sem saber. antigamente eu utilizava o template method sem saber.

a didática de aprender padrões de projeto, tratando-se de padrões da GoF ou GRASP neste caso, é justamente um ato de exercitar bons princípios de O.O, para velhos problemas conhecidos e que serão recorrentes ao longo da nossa atuação profissional, de forma que um determinado design descreva características de um ou mais padrões, resumindo-se em poucas palavras.

agora, se você souber fazer bom uso disto sem conhecer padrões e explicar como algo foi desenvolvido, você está no caminho mais do que certo, visto vez que, eles devem ser mencionados quando necessário, e isto é verdade porque nosso objetivo final é concluir um projeto atendendo a contento o mais simples possível de forma a minimizar custo, em prazo e que possibilite que a equipe se comunique em seu ritmo natural de forma a evoluir sem depender de padrões e catálogos como referências e normas em suas práticas atuais, e futuras pois podem acabar não sendo promissoras.

abusar do uso de padrões de projeto pode fazer mal a nossa saúde e a do projeto que estamos tratando!

Há uma sutil, mas gritante diferença entre saber como usar padrões de projeto e saber quando usar padrões de projeto.

victorwss wrote:Há uma sutil, mas gritante diferença entre saber como usar padrões de projeto e saber quando usar padrões de projeto.

sutil, mas gritante ??? por exemplo ???

This message was edited 1 time. Last update was at 07/11/2009 16:11:35

faelcavalcanti wrote:

victorwss wrote:Há uma sutil, mas gritante diferença entre saber como usar padrões de projeto e saber quando usar padrões de projeto.

sutil, mas gritante ??? por exemplo ???

Sim, sutil e gritante ao mesmo tempo.
É uma diferença pequena, mas que pode decidir entre a vida e a morte.

Saber como usar é entender como funciona o Façade, por exemplo, que cara ele tem, como implementar e que mecanismo ele usa.
Saber quando usar é identificar onde ele deve ser usado e onde ele não deve ser usado. Afinal, como eu já disse outras vezes aqui no GUJ, usar um padrão no lugar errado, na circunstância errada, transforma o padrão em anti-padrão.

Enfim, eu estava concordando com você. Abusar de padrões é ruim.
Os padrões podem ser comparados a remédios, para curar problemas no código. Pessoas que abusam de remédios tem saúde pior do que aqueles que não tomam nenhum.
E se você tem um problema no coração, deve tomar o remédio para o coração, não o remédio para o fígado!

This message was edited 1 time. Last update was at 08/11/2009 02:53:58

só queria destacar alguns pontos desta mesma entrevista apresentada por paulo inicialmente e que li só agora rapidamente:

(1) Larry perguntou se existe um novo formato na imagem que mostra o relacionamento entre os padrões. Até aí me parece óbvio a resposta que Ralph deu.

Larry: For a while, everything became a "pattern." There were patterns for architecture, organizational behavior, analysis, etc. What was less apparent, though, was an evolution where the 23 patterns in the DP catalog were extended by X other design patterns or related to, say, architectural patterns. There are a lot of patterns out there. Is there a new "Figure 1.1: Design pattern relationships"?

Figure 1.1: Design pattern relationships

Ralph: If you mean "Do we have a figure to give you?" the answer is "No." If you mean "Should someone create a new figure?" the answer is "Yes."

Então eu os pergunto:

Qual a verdadeira intenção em demonstrar o relacionamento entre os padrões a partir desta imagem, visto que outras possibilidades interessantes podem ser trabalhadas, e que alguns permanecem sozinhos ? (ps: não tenho o livro da GoF, justificando porque não lembro o que eles ressaltaram em sua referência sobre esta imagem, e sei apenas que eles quiseram demonstrar algumas possibilidades entre padrões que podem se relacionar como alternativa)

Mais abaixo do texto Erich menciona sobre os 200 padrões de Linda Rising. Ela deve ter dado um duro danado para juntar isto tudo, mas que Erich defende bem a idéia, "In other words, not all patterns have the same relevance and weight.", justificando a afortunação que eles devem ter passado, no qual faltou um pouquinho mais de engenharia social no trabalho tanto dela como deles, como por exemplo: juntando opinião de outros a respeito, defendendo e criticando, e não uma coisa imóvel como uma peça em um museu.

(2) Segundo e, último ponto, seria sobre a pergunta final feita, e pelo que percebi, muita coisa ainda está no rascunho e em pesquisa.

Interpreter and Flyweight should be moved into a separate category that we referred to as "Other/Compound" since they really are different beasts than the other patterns. Factory Method would be generalized to Factory.
The categories are: Core, Creational, Peripheral and Other. The intent here is to emphasize the important patterns and to separate them from the less frequently used ones.
The new members are: Null Object, Type Object, Dependency Injection, and Extension Object/Interface (see "Extension Object" in Pattern Languages of Program Design 3, Addison- Wesley, 1997).
These were the categories:
Core: Composite, Strategy, State, Command, Iterator, Proxy, Template Method, Facade
Creational: Factory, Prototype, Builder, Dependency Injection
Peripheral: Abstract Factory, Visitor, Decorator, Mediator, Type Object, Null Object, Extension Object
Other: Flyweight, Interpreter

Alguns padrões notoriamente foram inseridos, e outros ele não mencionou que não seriam removidos ou melhor justificado, apenas o caso do singleton, que ele declarou amá-lo de certa forma, como mencionado abaixo:

When discussing which patterns to drop, we found that we still love them all. (Not really?I'm in favor of dropping Singleton. Its use is almost always a design smell.)

Mas o que não entendi foi esta nova terminologia adicionando-se core e outros!
Ora, então vejamos a classificação anteriormente proposta pela GoF

por propósito: Criação + Estrutura + Comportamento
por escopo: classe e objeto

Metsker, autor de alguns livros como: Design Patterns in Java, propôs uma abordagem diferente, e, me pareceu mais apropriado, por intenção, lembrando que a intenção parte do pressuposto de um problema em um contexto inserido a ser solucionado. Segue abaixo:

Oferecer uma interface
Atribuir uma responsabilidade
Realizar a construção de classes e objetos
Controlar formas de operação
Implementar uma extensão para a aplicação

Já que falamos tanto de singleton, ele encontra-se como criação no GoF, mas como responsabilidade na classificação de Metsker, entre outros padrões variadamente.
Sei que ao final ele mencionou ser um rascunho apenas, mas esta taxonomia, dentro destas mudanças citadas, foi apropriada ?

isto tudo, se resumiria em uma resenha a esta entrevista, complementando-se destes questionamentos!

faelcavalcanti wrote:

Interpreter and Flyweight should be moved into a separate category that we referred to as "Other/Compound" since they really are different beasts than the other patterns. Factory Method would be generalized to Factory.
The categories are: Core, Creational, Peripheral and Other. The intent here is to emphasize the important patterns and to separate them from the less frequently used ones.
The new members are: Null Object, Type Object, Dependency Injection, and Extension Object/Interface (see "Extension Object" in Pattern Languages of Program Design 3, Addison- Wesley, 1997).
These were the categories:
Core: Composite, Strategy, State, Command, Iterator, Proxy, Template Method, Facade
Creational: Factory, Prototype, Builder, Dependency Injection
Peripheral: Abstract Factory, Visitor, Decorator, Mediator, Type Object, Null Object, Extension Object
Other: Flyweight, Interpreter

Alguns padrões notoriamente foram inseridos, e outros ele não mencionou que não seriam removidos ou melhor justificado, apenas o caso do singleton, que ele declarou amá-lo de certa forma, como mencionado abaixo:

Pois é. O que haveria de errado no Chain of Responsability, Adapter, Proxy, Memento e Bridge?

Ah, e na minha opinião esse negócio de criar figurinha com um grafo relacionando os patterns é pura bobagem. Não ajuda em nada e serve para confundir.

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

faelcavalcanti wrote:

sergiotaborda wrote:Porque o MVC está associado a controles fisicos como teclado e mouse, as pessoas assumem que é um padrão arqutietural, mas não é. Para ser um padrão arquitetural ele teria que interferir com plataformas, andares (que eu chamei camadas neste texto) , nodos ou protocolos de comunicação. Ele não interfere com nada disto, logo não é um padrão de arquitetura. Embora existam muitos desavisados que o chamam assim.

um padrão realmente de arquitetura é o Cluster, por exemplo.

você demonstrou um exemplo, não necessariamente, ele, se resume a isto! sempre tenho visto o modelo MVC como padrão arquiteturial, me mostre uma referência que o dita que não o seja, que eu me convencerei!

Primeiro que tudo não estou preocupado se vc está convencido. Segundo , não estou preocupado com o seu complexo de são tomé.
Terceiro se realmente quer entender , pense um pouco. Vc acha que MVC está no mesmo nivel de responsabilidade que padrões arquiteturais como cluster, peer-to-peer , soa ou pipeline ? Se não acha, ai está a sua demonstração. Se acha, então tente explicar o que MVC têm em comum com pipeline ou p2p ou mesmo cluster, e como essas coisas em comum dizem respeito a arquitetura. (este é um desafio retorico)

Bom, antes que pergunte : arquitetura trata sobre a interação de sistemas. Aplicações são constituidas por um mais sistemas.
Por exemplo, falamos em "arquitetura web" porque estamos falando de 2 sistemas : o browser e o servidor.
Arquitetura não trata de codigo, linguagens, OO ou coisa semelhante.

sergiotaborda wrote:Primeiro que tudo não estou preocupado se vc está convencido. Segundo , não estou preocupado com o seu complexo de são tomé.
Terceiro se realmente quer entender , pense um pouco. Vc acha que MVC está no mesmo nivel de responsabilidade que padrões arquiteturais como cluster, peer-to-peer , soa ou pipeline ? Se não acha, ai está a sua demonstração. Se acha, então tente explicar o que MVC têm em comum com pipeline ou p2p ou mesmo cluster, e como essas coisas em comum dizem respeito a arquitetura. (este é um desafio retorico)

sua arrogância está complicando você mesmo, além dos outros leitores deste tópico.

eu não disse que está no mesmo nível de responsabilidade, você está misturando as coisas e, complementando com falsas informações suas.
pedi a você que me contextualize de suas afirmações com referências, não com afirmações indiretas e excrupulosas. e por favor guarde as para você, e isso não é nada bom para você!

temos o direito de divergir, e respeito opniões, contradições, conceitos, preceitos e hoje no mundo moderno: preconceitos!

sergiotaborda wrote:Bom, antes que pergunte : arquitetura trata sobre a interação de sistemas. Aplicações são constituidas por um mais sistemas.

argumento válido, mas se resume a isto?

parece que você bateu com a cabeça, mas vamos lá: segundo POSA1, temos inúmeros modelos de arquitetura com propósitos específicos ditos por Buschman, 1996, eis alguns como:

structure: layers, pipes & filters, blackborad
distributed: broker
interactive: mvc, pac
adaptable: microkernel, reflection

agora, Buschman 1996, muito tempo se passou de lá para cá, e sei disto! eu sinceramente ainda concordo com outras vertentes, assim como Fowler/06 com alguns pontos de vistas dele com artigo GUI Architectures, como consequente review do seu livro de EEAI, no qual menciona visão do MVC clássico com, dito por alguns WEB MVC.

outro ponto, por favor, não vamos ficar no blablabla aqui sobre MVC, não estamos na época do barroco! eu propus a idéia de abordar isto em outro tópico sobre padrões de arquitetura, como premissa discutindo duas perguntas iniciais que citei.

Você concorde ou não um trabalho bem mais exaustivo disto renderia no mínimo um artigo acadêmico.

Novamente, não estamos na era do barroco, no filme hair, ou quer que seja época você vive, mas podemos discutir outras vertentes que te motivaram ao seu pensamento e ponto de vista, .... em outro tópico ou via MP! A decisão é sua, e paro por aqui!

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