A Gangue dos Quatro explorou completamente o "Espaço Padrão"?

Quando o livro saiu, muitas pessoas pensaram dessa maneira, e houve muitos esforços para criar "bibliotecas de padrões" ou até mesmo "comunidades padrão". Você ainda pode encontrar alguns deles:

• "Comunidade padrão" , WikiWikiWeb
• "O Grupo de Estudo de Padrões de Design da Cidade de Nova York" , Lógica Industrial
• "Catálogo de Padrões" , The Hillside Group

Mas então ...

Did the interest in finding new patterns drop, maybe because they are not really that useful in software design?

Isso, muito mesmo. O ponto dos padrões de design é melhorar a comunicação entre os desenvolvedores, mas se você tentar adicionar mais padrões, chegará rapidamente ao ponto em que as pessoas não conseguirão lembrá-las ou não as lembrará, nem discordarão sobre o que exatamente elas deve parecer, e a comunicação não é, de fato, melhorada. Isso já acontece muito com os padrões do GoF.

E muitas pessoas se encantam com o conceito e tentam aplicar padrões em todos os lugares - normalmente, no código resultante, você não consegue encontrar o design real entre todas as Singletons e Abstract Factories (sem sentido).

I am having the impression that these 23 patterns should be only a small sample of something much larger which I like to call the Pattern Space.

Esta é a terrível suposição que é propagada por programadores neófitos em todos os lugares, programadores que pensam que podem escrever um programa simplesmente unindo padrões de software. Não funciona assim. Se houver tal "espaço padrão", você pode assumir que seu tamanho é efetivamente infinito.

Padrões de design (no sentido GoF) têm apenas uma finalidade: para compensar deficiências na linguagem de programação que você está usando.

Padrões de design não são universais nem abrangentes. Se você mudar para uma linguagem de programação diferente e mais expressiva, a maioria dos padrões no livro do GoF se tornará desnecessária e indesejável.

Eu acho que existem três fatores que entram em jogo aqui.

Falta de massa crítica

Primeiro, um padrão é basicamente pouco mais que dar um nome a algum código que implementa um "pedaço" específico de funcionalidade. A única maneira que o nome fornece muito valor real é se você pode depender de todos sabendo o que o nome significa, apenas usando o nome, eles imediatamente entendem muito sobre o código.

Os padrões nunca estabeleceram a massa crítica necessária para isso. Pelo contrário, o AAMOF. Nos 20 (ou mais) anos que se passaram desde o lançamento do livro GoF, tenho certeza de que não vi mais de uma dúzia de conversas em que todos os envolvidos realmente conheciam padrões de design suficientes para seu uso para melhorar a comunicação.

Para colocá-lo um pouco mais curiosamente: padrões de design falharam especificamente porque falharam.

Muitos padrões

Eu acho que o segundo fator principal é que, se qualquer coisa, eles inicialmente nomearam muitos padrões. Em um bom número de casos, as diferenças entre os padrões são suficientemente sutis, o que é quase impossível dizer com certeza se uma determinada classe se encaixa em um padrão ou outro (ou talvez ambos - ou talvez nenhum).

A intenção era que você pudesse falar sobre código em um nível mais alto. Você seria capaz de rotular um grande pedaço de código como a implementação de um padrão específico. Simplesmente usando esse nome pré-definido, todo mundo escutando normalmente saberia tanto quanto eles se importavam com esse código, então você poderia passar para a próxima coisa.

A realidade tende a ser quase o oposto. Digamos que você esteja em uma reunião e diga a eles que essa aula em particular é uma Fachada. Metade das pessoas na reunião nunca soube ou esqueceu há muito tempo exatamente o que isso significa. Um deles pede para você lembrar a diferença exata entre uma fachada e, digamos, uma procuração. Ah, e o casal de pessoas que realmente conhece padrões passam o resto da reunião debatendo se isso realmente deveria ser considerado uma Fachada ou "apenas" um Adaptador (com aquele cara ainda insistindo que parece um Proxy para ele).

Dado que a sua intenção era apenas dizer: "este código não é muito interessante; vamos seguir em frente", tentando usar o nome de um padrão apenas adicionou distração, não valor.

Falta de interesse

A maioria dos padrões de design não lida com as partes interessantes do código. Eles lidam com coisas como: "como eu crio esses objetos?", E "como faço para que esse objeto fale com esse?" Memorizar nomes de padrões para estes (assim como os argumentos acima mencionados sobre detalhes e tal) é simplesmente colocar muita energia em coisas que a maioria dos programadores simplesmente não se importam muito com isso.

Para colocar de forma um pouco diferente: os padrões lidam com as coisas que são as mesmas entre muitos programas - mas o que realmente torna um programa interessante é como ele é diferente de outros programas.

Resumo

Padrões de design falham porque:

1. Eles não conseguiram atingir massa crítica.
2. A diferenciação entre padrões foi insuficiente para garantir clareza.
3. Eles lidam principalmente com partes do código que quase ninguém realmente se importava de qualquer maneira.

Padrões estão faltando abstrações, padrões simples são abstraídos, padrões complexos não são reconhecidos, então padrões não são úteis (exceto alguns de alto nível).

Acho que Paul Graham disse melhor:

When I see patterns in my programs, I consider it a sign of trouble. The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I'm using abstractions that aren't powerful enough-- often that I'm generating by hand the expansions of some macro that I need to write.

Quando você reconhece um padrão em seu código, isso significa que algo se repete e você deve usar uma melhor abstração. Se você não tiver uma melhor abstração, use o padrão como uma solução alternativa. Como novas linguagens de programação fornecem melhores abstrações, os padrões se tornam muito menos úteis.
Padrões simples também são facilmente abstraídos e padrões complexos raramente são reconhecidos.
Quando um padrão é substituído por uma abstração, isso não significa que o conceito por trás do padrão desaparece, mas que o conceito pode ser escrito explicitamente em vez de indireto e que não é mais especial comparado a outro código e torna-se não mais reconhecível como um padrão.

Algo que nenhuma das outras respostas menciona também é relevante:

O surgimento de linguagens dinamicamente tipificadas.

Quando o primeiro livro saiu, houve uma discussão séria de que Java era muito lento para fazer um trabalho real. Agora, o Java é frequentemente usado em linguagens mais expressivas porque de sua velocidade. Talvez Ruby, Python, JavaScript e outros ainda sejam lentos demais para algumas classes importantes de aplicativos, mas, em geral, são rápidos o suficiente para a maioria das finalidades. E o JavaScript, pelo menos, está ficando mais rápido, apesar de ter mais recursos em cada versão.

O livro original do GoF tinha os padrões em smalltalk e c ++, e se a memória serve, os padrões eram sempre mais curtos no smalltalk e, às vezes, significativamente. Alguns dos recursos dos padrões de design clássicos são, na verdade, maneiras de adicionar recursos dinâmicos a um sistema de tipo estaticamente (como o AbstractFactory já discutido, no qual você instancia a classe correta com base nos dados de tempo de execução). Outros são muito mais curtos em linguagens dinâmicas que simplesmente se misturam ao uso idiomático da própria linguagem.

aconteceu . Dezenas, senão centenas, de livros foram publicadas no que parecia ser uma tentativa de reduzir o todo da ciência da computação a padrões de design, à medida que editores e autores tentavam pular (ou criar) mais uma onda. Eu tenho uma prateleira deles. Nunca fui consultado desde o primeiro escaneado, e sim, eu era um otário, porque havia pouco ou nada de uso real ou que já não era bem conhecido (veja por exemplo Type Object, que nada mais é que uma terceira forma normal expressa sobre uma dúzia de páginas em vez de um parágrafo), e porque, obviamente, quanto menos padrões, melhor: um ponto que iludiu a maioria dos praticantes. De fato, quando publiquei uma réplica do Type Object, fui instruído a reformular meu texto como um padrão de design. História verdadeira. O que também mostra outra deficiência do projeto: nenhum mecanismo de revisão, exclusão ou rejeição.

Na verdade, o GoF na verdade não tentou "explorar completamente os Padrões de Design". Em vez disso, eles estavam engajados em um projeto muito maior: introduzir 'linguagem de padrão' no CS, com todos os seus bizarros arcanos notacionais de Forças, Participantes, etc., que simplesmente falharam, porque foi fundamentalmente mal concebido, além de ser inútil.

O que eles realizaram , o que foi útil, foi duas coisas:

• publique vários truques úteis, como o padrão de visitante
• fornece um conjunto padrão de nomes que ficou em grande parte preso: Factory, Adapter, Iterator, ... Se você olhar para o CORBA, que foi projetado de antemão, verá o valor disso: todos os tipos de nomes 'estrangeiros' como Interceptor, Servant, Broker, ...

Outro conceito útil que surgiu foi o "anti-padrão", e. 'log and throw'. O projeto, como muitos modismos no CS, foi descarrilhado por seu próprio evangelismo e por ser erroneamente adotado como mais uma religião CS, e seguiu o caminho da maioria dessas religiões: útil em partes, mas certamente "sem bala de prata" (c ) Fred Brooks, 1965). É triste que tenhamos que continuar redescobrindo isso a cada poucos anos.

Havia vários livros intitulados PLoP ( Padrões de linguagens de design de programa ), que são, cada uma, uma antologia de trabalhos apresentados em uma conferência anual .

Lendo os livros, descobri que alguns dos padrões eram interessantes e novos para mim, alguns deles padrões (por exemplo, "meio objeto mais protocolo").

Portanto, não, a coleção do GoF não foi exaustiva e inspirou / inspira as pessoas a coletar / descrever / descobrir / inventar novas.

Os "apenas 12 padrões adicionais listados no artigo da Wikipedia" presumivelmente não são uma coleção completa: ou seja, há outros documentados em outro lugar, por exemplo, nos livros PLoP e talvez em outros lugares também.

O livro Gang of Four (GoF) contém a maioria dos padrões que um programador experiente em uma linguagem não funcional tem em seu cinto de ferramentas. É como o conjunto básico de ferramentas que todos os construtores sabem usar. A principal contribuição do livro foi dar um nome bem definido aos padrões que estavam em uso comum pelos programadores mais experientes no momento e, portanto, ajudar na comunicação entre os programadores que discutem as opções de design.

Você espera que um eletricista tenha algumas ferramentas que um construtor normal não possui, da mesma forma você esperaria que um programador do WPF conhecesse os padrões de design para “Propriedades de Dependência” ou um “Programador SQL” para conhecer o padrão de design. usando gatilhos para criar dados de auditoria.

No entanto, não pensamos neles como "Padrões de design", pois eles só são usados com uma única tecnologia.

Alguns livros de padrões de design mais modernos são “Refatorando, melhorando o design do código existente (Martin Fowler)” e “Código Limpo: Um Manual de Artesanato Ágil de Software (Robert C. Martin) ” Ambos os livros apresentam o conteúdo como transformações que você faz no seu código atual, em vez de“ design reutilizável pré-enlatado ”, no entanto, eles são apenas“ padrões de design ”.

Os padrões reais do livro às vezes são realmente úteis, mas na verdade são apenas instâncias de uma ferramenta mais poderosa que o livro oferece: um profundo entendimento de quando e onde é melhor cortar código monolítico em partes independentes separadas e reguladas por uma interface.

Quando você aprende essa habilidade, percebe que não precisa se lembrar dos detalhes exatos de cada padrão, pois você pode sempre cortar a solução que está implementando da maneira que melhor se adapte ao seu propósito. Assim, a ideia de escrever mais e mais padrões parece muito acadêmica e sem sentido.

So I expected the number of known and documented design patterns to grow significantly.

It did not happen. More than 20 years after the GoF book came out, only 12 additional patterns are listed in the Wikipedia article, most of which are much less popular than the original ones. (I did not include the concurrency patterns here because they cover a specific topic.)

O livro GoF e a Wikipédia dificilmente são a única fonte de padrões de design conhecidos. Se você apenas procurar por "padrões de design" na Amazon.com, você terá centenas de livros (experimente este pesquisa ). Eu acho que eles listam apenas o padrão mais conhecido no artigo da Wikipedia .

Portanto, o problema não é que não haja padrões de design documentados suficientes. Em vez disso, existem tantos que ninguém consegue memorizá-los e a maioria dos programadores reconhece apenas alguns. A grande promessa da linguagem de padrões comuns é quebrada neste ponto.

Aqui está uma entrevista com Erich Gamma, onde ele reflete sobre sua seleção de padrões e o que eles mudariam hoje (bem hoje, há 10 anos, haha).

link

Larry: How would you refactor "Design Patterns"?

Erich: We did this exercise in 2005. Here are some notes from our session. We have found that the object-oriented design principles and most of the patterns haven't changed since then. We wanted to change the categorization, add some new members and also drop some of the patterns. Most of the discussion was about changing the categorization and in particular which patterns to drop.

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.)

So here are some of the changes:

• 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

Existem provavelmente muitas estruturas que ainda não foram pensadas. Enquanto as pessoas estiverem desenvolvendo software, haverá desafios de design a serem superados. Algumas delas podem ser resolvidas usando novos padrões inteligentes que outros poderiam usar.

As linguagens de programação se desenvolveram e progrediram para abstrair os padrões mais usados. Esses padrões ainda existem no design das linguagens. Então eles podem ser ignorados hoje, mas isso não os torna sem importância.

O conhecimento de como construir uma casa de repente não é importante quando temos robôs que podem fazer isso por nós? Eu diria que não, não é. É menos relevante, claro - e provavelmente muito menos gratificante estudar, já que a demanda caiu drasticamente, e ninguém mais está estudando isso.

Então, não, eu não acredito que o espaço padrão, como você chama, esteja esgotado. Como outra resposta apontou, é provável que seja infinito. Mas à medida que a demanda por projeto de sistemas diminui, à medida que aumentamos a altura de nossa torre de abstração e o poder de nossas linguagens de programação - cada vez menos pessoas construindo nas camadas superiores prestarão atenção aos detalhes de como a torre foi construída .

Os padrões são infinitos. Você pode ajustar cada padrão ou misturar n combinações para criar novas. Padrões de integração da empresa também são bem definidos ... Então, sim, Gof fez testes para documentar padrões usando uml e criou um padrão para explicá-los. .. Mas para cada domínio padrões evoluem e eles também mudam para linguagem expressiva como python ou scala ..