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

Desde que aprendi sobre os padrões de design do Gang of Four (GoF) , há pelo menos 10 anos, tenho a impressão de que esses 23 padrões devem ser apenas uma pequena amostra de algo muito maior que eu gosto de chamar de Espaço de Padrão . Esse espaço de padrão hipotético consiste em todas as soluções recomendáveis ​​(conhecidas ou desconhecidas) para problemas comuns de design de software orientado a objetos.

Então, eu esperava que o número de padrões de design conhecidos e documentados aumentasse significativamente.

Isso não aconteceu. Mais de 20 anos após a publicação do livro GoF, apenas 12 padrões adicionais estão listados no artigo da Wikipedia, a maioria dos quais é muito menos popular que os originais. (Eu não incluí os padrões de simultaneidade aqui porque cobrem um tópico específico.)

Quais são as razões?

• O conjunto de padrões do GoF é realmente mais abrangente do que eu penso?

• O interesse em encontrar novos padrões diminuiu, talvez porque se descobriu que eles não eram tão úteis no design de software?

• Algo mais?

Quando o livro foi lançado, muitas pessoas pensaram assim, e houve muitos esforços para criar "bibliotecas de padrões" ou mesmo "comunidades de padrões". Você ainda pode encontrar alguns deles:

• "Comunidade de padrões" , WikiWikiWeb
• "O Grupo de Estudo de Padrões de Design da cidade de Nova York" , Industrial Logic
• "Catálogo de padrões" , The Hillside Group

Mas então...

O interesse em encontrar novos padrões caiu, talvez porque eles não sejam realmente tão úteis no design de software?

Isso muito. O objetivo dos padrões de design é melhorar a comunicação entre os desenvolvedores, mas se você tentar adicionar mais padrões, rapidamente chegará ao ponto em que as pessoas não se lembram deles, ou se lembram deles, ou discordam sobre como exatamente deveriam ser, e a comunicação é de fato, não melhorou. Isso já acontece muito com os padrões GoF.

Pessoalmente, eu iria ainda mais longe: o design de software, especialmente o bom design de software, é muito variado para ser capturado de maneira significativa em padrões, especialmente no pequeno número de padrões que as pessoas conseguem se lembrar - e são abstratos demais para as pessoas. realmente lembre-se de mais do que um punhado. Então eles não estão ajudando muito.

E muitas pessoas ficam apaixonadas pelo conceito e tentam aplicar padrões em todos os lugares - normalmente, no código resultante, não é possível encontrar o design real entre todos os Singletons e Fábricas Abstratas (completamente sem sentido).

Estou com a impressão de que esses 23 padrões devem ser apenas uma pequena amostra de algo muito maior que eu gosto de chamar de Espaço Padrão.

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

Os padrões de design (no sentido GoF) têm apenas um objetivo: compensar deficiências na linguagem de programação que você está usando.

Os 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 GoF se tornará desnecessário 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 do que dar um nome a algum código que implementa um "pedaço" de funcionalidade específico. A única maneira pela qual o nome fornece muito valor real é se você pode confiar em todos que sabem o que o nome significa, então, usando o nome, eles imediatamente entendem bastante sobre o código.

Os padrões nunca estabeleceram a massa crítica necessária para conseguir isso. Antes pelo contrário, AAMOF. Nos 20 (mais ou menos) anos desde que o livro do GoF foi lançado, tenho certeza de que não assisti a uma dúzia de conversas nas quais todos os envolvidos realmente conheciam padrões de design suficientes para melhorar a comunicação.

Em outras palavras: os padrões de design falharam especificamente porque falharam.

Muitos padrões

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

A intenção era que você pudesse falar sobre código em um nível superior. Você seria capaz de rotular um pedaço de código bastante grande como a implementação de um padrão específico. Simplesmente usando esse nome predefinido, todo mundo que escuta normalmente sabe o quanto se importa com esse código, para que você possa 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 classe em particular é uma fachada. Metade das pessoas na reunião nunca soube ou há muito se esqueceu exatamente do que isso significa. Um deles pede que você lembre as diferenças exatas entre uma fachada e, por exemplo, um proxy. Ah, e as pessoas que realmente conhecem padrões passam o resto da reunião debatendo se isso realmente deve ser considerado uma Fachada ou "apenas" um Adaptador (com aquele cara ainda insistindo que isso parece um Proxy para ele).

Dado que sua intenção era realmente apenas dizer: "esse código não é muito interessante; vamos seguir em frente", tentando usar o nome de um padrão apenas para adicionar 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 crio esses objetos?" E "como faço para que esse objeto fale com aquele?" Memorizar nomes de padrões para esses (bem como os argumentos acima mencionados sobre detalhes e outros) é simplesmente colocar muita energia em coisas que a maioria dos programadores simplesmente não se importa.

Em outras palavras: os padrões lidam com as coisas iguais entre muitos programas - mas o que realmente torna um programa interessante é como ele é diferente de outros programas.

Sumário

Os padrões de design falharam porque:

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

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

Eu acho que Paul Graham disse o melhor:

Quando vejo padrões nos meus programas, considero isso um sinal de problemas. A forma de um programa deve refletir apenas o problema que ele precisa resolver. Qualquer outra regularidade no código é um sinal, pelo menos para mim, de que estou usando abstrações que não são poderosas o suficiente - geralmente estou gerando manualmente as expansões de alguma macro que preciso escrever.

Quando você reconhece um padrão no seu código, isso significa que algo se repete e você deve usar uma abstração melhor. Se você não tiver uma abstração melhor, use o padrão como 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 costumam ser facilmente abstraídos e padrões complexos raramente 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 em comparação com outro código e deixa de ser reconhecível como um padrão.

Embora eu concorde principalmente com o que os outros responderam aqui, pessoalmente acho que a principal razão para um número não crescente de padrões é que os padrões perdem seu significado quando existem inúmeros. O bom desses poucos padrões é que eles cobrem muitos domínios problemáticos de maneira padrão. Se você focasse em um domínio de padrão sem fim, acabaria sem nenhum padrão. É um pouco como "quanto tempo dura a costa de uma ilha?". Se você medir em um mapa, você vem com um número decente. Mas se você tentar obter mais precisão e chegar a uma resolução mais precisa, descobrirá que o comprimento aumenta cada vez mais para o infinito (ou incerteza; como você mede a borda exata com as marés e no nível atômico?).

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

O surgimento de linguagens de tipo dinâmico.

Quando o livro foi lançado, houve uma discussão séria de que o Java era muito lento para realizar um trabalho real. Agora, o Java é frequentemente usado em linguagens mais expressivas devido à sua velocidade. Talvez Ruby, Python, JavaScript etc. ainda sejam muito lentos para algumas classes importantes de aplicativos, mas, em geral, são rápidos o suficiente para a maioria dos propósitos. E, pelo menos, o JavaScript está realmente 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 servir, os padrões eram sempre mais curtos em smalltalk e, às vezes, significativamente. Alguns dos recursos dos padrões clássicos de design são realmente maneiras de adicionar recursos dinâmicos a um sistema estaticamente digitado (como o AbstractFactory já discutido, no qual você instancia a classe correta com base nos dados de tempo de execução). Outros são tão mais curtos em linguagens dinâmicas que simplesmente se fundem no uso idiomático da própria linguagem.

Ele fez acontecer. Dezenas senão centenas de livros foram publicados, no que parecia uma tentativa de reduzir toda a ciência da computação a padrões de design, enquanto editores e autores tentavam pular (ou criar) mais um movimento. Eu tenho uma prateleira deles. Nunca foi consultado desde a primeira varredura, e sim, eu era um otário, porque havia pouco ou nada de uso real ou que ainda não era bem conhecido (veja, por exemplo, Tipo de objeto, que nada mais é do que a 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 postei uma refutação do Type Object, fui instruído a reformular meu texto como um padrão de design.História real. O que também mostra outra deficiência do projeto: nenhum mecanismo de revisão, exclusão ou rejeição.

Por uma questão de fato, o GoF não tentou 'explorar completamente os Padrões de Design'. Em vez disso, eles estavam envolvidos em um projeto muito maior: introduzir 'linguagem de padrões' no CS, com todos os seus arcanos notáveis ​​bizarros de Forças, Participantes etc., que simplesmente falharam, porque eram fundamentalmente mal concebidos, além de serem inúteis.

O que eles se realizar, que foi útil, foi duas coisas:

• publique vários truques úteis, como o padrão Visitor
• forneça um conjunto padrão de nomes que permaneceu em grande parte: Fábrica, Adaptador, Iterador, ... Se você observar o CORBA, que foi projetado imediatamente antes, verá o valor disso: todos os tipos de nomes "estrangeiros", como Interceptor , Empregado, Corretor, ...

Outro conceito útil que surgiu foi o 'antipadrão', por exemplo, 'log and throw'. O projeto, como muitos modismos no CS, foi atrapalhado por seu próprio evangelismo e por ter sido adotado erroneamente como mais uma religião do 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 redescobrir isso realmente a cada poucos anos.

Havia / existem vários livros intitulados PLoP ( Pattern Languages ​​of Program Design ), cada um deles uma antologia de trabalhos apresentados em uma conferência anual .

Ao ler os livros, achei alguns dos padrões 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" provavelmente também não são uma coleção completa: ou seja, existem outros documentados em outros lugares, 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 possui 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 eram de uso comum pelos programadores mais experientes da época e, portanto, auxiliar 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 que você esperaria que um programador WPF conheça os padrões de design para "Propriedades de Dependência" ou um "Programador SQL" para conhecer o padrão de design para usar gatilhos para criar dados de auditoria.

No entanto, não pensamos neles como "padrões de design", porque eles são usados ​​apenas com uma tecnologia.

Alguns livros sobre padrões de design de modem são “Refatoração, aprimorando o design de código existente (Martin Fowler)” e “Código limpo: um manual de artesanato em software ágil (Robert C. Martin) ”. Ambos os livros apresentam o conteúdo como transformações que você faz ao seu código atual, e não como "design reutilizável pré-enlatado", no entanto, eles são apenas "padrões de design".

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

http://www.informit.com/articles/article.aspx?p=1404056

Larry: Como você refatoraria "Design Patterns"?

Erich: Fizemos este exercício em 2005. Aqui estão algumas notas de nossa sessão. Descobrimos que os princípios de design orientado a objetos e a maioria dos padrões não foram alterados desde então. Queríamos alterar a categorização, adicionar novos membros e também remover alguns dos padrões. A maior parte da discussão foi sobre como alterar a categorização e, em particular, quais padrões serão eliminados.

Ao discutir quais padrões serão eliminados, descobrimos que ainda amamos todos eles. (Na verdade não - sou a favor de abandonar Singleton. Seu uso é quase sempre um cheiro de design.)

Então, aqui estão algumas das mudanças:

• Intérprete e Flyweight devem ser movidos para uma categoria separada que chamamos de "Outro / Composto", pois eles realmente são bestas diferentes dos outros padrões. O Método de Fábrica seria generalizado para Fábrica.
• As categorias são: Core, Creational, Peripheral e Other. A intenção aqui é enfatizar os padrões importantes e separá-los dos menos usados.
• Os novos membros são: Objeto Nulo, Objeto Tipo, Injeção de Dependência e Objeto / Interface de Extensão (consulte "Objeto de Extensão" em Linguagens Padrão do Design de Programa 3, Addison-Wesley, 1997).
• Estas foram as categorias:
  • Núcleo: Composto, Estratégia, Estado, Comando, Iterador, Proxy, Método de Modelo, Fachada
  • Criação: Fábrica, Protótipo, Construtor, Injeção de Dependência
  • Periférico: Abstract Factory, Visitante, Decorador, Mediador, Tipo de objeto, Objeto nulo, Objeto de extensão
  • Outros: Flyweight, Intérprete

Às vezes, os padrões reais do livro são realmente úteis, mas na verdade são apenas exemplos de uma ferramenta mais poderosa que o livro oferece: uma compreensão profunda 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 sempre pode cortar a solução que está implementando da maneira que melhor se ajusta ao seu objetivo. Portanto, a ideia de escrever cada vez mais padrões parece muito acadêmica e sem sentido.

Então, eu esperava que o número de padrões de design conhecidos e documentados aumentasse significativamente.

Isso não aconteceu. Mais de 20 anos após a publicação do livro GoF, apenas 12 padrões adicionais estão listados no artigo da Wikipedia, a maioria dos quais é muito menos popular que os originais. (Eu não incluí os padrões de simultaneidade aqui porque cobrem um tópico específico.)

O livro GoF e a Wikipedia dificilmente são a única fonte de padrões de design conhecidos. Se você apenas pesquisar "padrões de design" na Amazon.com, receberá centenas de livros (tente esta 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 pode memorizar todos eles e a maioria dos programadores reconhece apenas alguns. A grande promessa da linguagem padrão comum se quebra nesse ponto.

Provavelmente, existem muitas estruturas que ainda não foram pensadas. Enquanto as pessoas estiverem desenvolvendo software, haverá desafios de design a serem superados. Alguns deles podem muito bem ser resolvidos 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 dos idiomas. Portanto, eles podem ser ignorados hoje, mas isso não os torna sem importância.

O conhecimento de como construir uma casa repentinamente não é importante quando temos robôs que podem fazer isso por nós? Eu diria que não, não é. É menos relevante, com certeza - e provavelmente muito menos gratificante para estudar, pois a demanda caiu drasticamente e ninguém mais a estuda.

Então não, eu não acredito que o espaço padrão como você chama tenha sido esgotado. Como outra resposta apontada, é provável que seja infinito. Porém, à medida que a demanda por design 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 construídas nas camadas superiores prestam atenção aos detalhes de como a torre foi construída .

Os padrões são infinitos. Você pode ajustar cada padrão ou combinar n para criar novos padrões. Os padrões de integração corporativa também são bem definidos. para cada domínio, os padrões evoluem e também mudam para uma linguagem expressiva como python ou scala.