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

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

sutil, mas gritante ??? por exemplo ???[/quote]

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!

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

[quote]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.”[/quote]
Então eu os pergunto:

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.

[quote]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
[/quote]

[quote]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:

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

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:

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 ?[/quote]
isto tudo, se resumiria em uma resenha a esta entrevista, complementando-se destes questionamentos!

[quote=faelcavalcanti][quote]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
[/quote]

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:
[/quote]

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.

[quote=faelcavalcanti][quote=sergiotaborda]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.
[/quote]
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!
[/quote]

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.

[quote=sergiotaborda]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)[/quote]
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!

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:

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! :wink: