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

144

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?

design-patterns object-oriented-design Frank Puffer
fonte
49
Os padrões estão em toda parte, mas são frequentemente usados ​​de maneira insípida e robótica. Por esse motivo, penso, a ideia do catálogo de padrões se tornou menos popular.
usr
6
Design de espaço? Alguém leve Mark Rosewater aqui embaixo, stat!
corsiKa
16
Martin Fowler publicou Patterns of Enterprise Application Architecture em 2003 documentando cerca de 50 padrões, muitos dos quais ainda são bastante reconhecíveis e bem utilizados atualmente, por exemplo, "Data Mapper", "Plugin", "Lazy Load", "Service Layer" etc.
Brian Rogers
2
Explorar o espaço de todos os padrões possíveis seria como não explorar o espaço de possíveis padrões. Você pode fazer de tudo um padrão. Se você faz de tudo um padrão, nada é um padrão, pois a palavra perde seu significado.
que você
4
@ BradThomas: Claro, como nas perguntas mais interessantes, as pessoas tendem a ter uma certa opinião. Mas as opiniões são pelo menos parcialmente baseadas em fatos, e eu encontrei muitos fatos interessantes nas respostas a essa pergunta que ajudarão a mim e, esperançosamente, outros a repensar suas opiniões e chegar a outras mais substanciais.
Frank soprador

Respostas:

165

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:

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

Michael Borgwardt
fonte
50
Opinião controversa: A fábrica abstrata é um cheiro de código de qualquer maneira :)
MetaFight
66
Opinião controversa, talvez, mas uma opinião tão importante para expressar. Os padrões de design correm o risco de se tornar um exemplo das novas roupas do imperador, onde todos temos medo de questionar se são úteis. Bem feito.
22616 David Arno
18
@MetaFightControversialDesignPatternOnlineOpinionHumanReadableRetortFactory.newInstance().getText();
corsiKa 13/11
11
" O objetivo dos padrões de design é melhorar a comunicação entre os desenvolvedores. " Eu pensei que os padrões de design eram para resolver problemas que eram comumente encontrados (e frequentemente de forma independente) pelos desenvolvedores. Os padrões melhoram a comunicação e, devido a flutuações (padrões decorrentes de problemas XY, padrões considerados anti-padrões), muitos não consideram padrões de design padrões. Os padrões de design são bons em apontar a falta de recursos de linguagem, e acredito que os designers de linguagem estão implementando essas correções de problemas antes que se tornem padrões de design.
Porém
11
@ Chrishr: Não entendo seu ponto de vista ... Como eu disse, o GoF tentou superar as deficiências de OO, e especialmente as deficiências de C ++ 98, pois essa era a linguagem de sua escolha junto com o Smalltalk. Eles realmente escreveram: "A escolha da linguagem de programação é importante porque influencia o ponto de vista de alguém. Nossos padrões assumem os recursos da linguagem no nível Smalltalk / C ++, e essa escolha determina o que pode e não pode ser implementado facilmente".
Shautieh
108

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.

Robert Harvey
fonte
40
"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." Eu continuo ouvindo isso, mas ainda tenho que ver isso justificado. Toda suposta justificativa aponta apenas para um punhado de padrões que são mais fáceis de implementar em idiomas com algum recurso - geralmente Visitor e talvez Singleton - e deixa intocada a grande maioria dos padrões, apenas implicando que eles também podem ser redundantes por linguagens melhores. Mas como sabemos? Que recurso de idioma torna o Observer irrelevante? Cadeia de Responsabilidade? Composto?
Jules
56
@Jules Somente as funções de primeira classe eliminam uma parte considerável delas, incluindo a Cadeia de Responsabilidade (é apenas a composição de uma lista de funções). A programação reativa funcional elimina o padrão Observer. O padrão Composite é apenas uma definição menos rigorosamente especificada de monoides, e linguagens com classes tipográficas e foco em leis algébricas fornecem ferramentas poderosas para trabalhar com monoides. Eu poderia listar muito mais, mas você entendeu.
Jack
12
@Jules: Eu acredito que o iterador listado no livro original do GoF é um padrão, mas agora sua transformação em recurso de linguagem está basicamente completa em todos os idiomas remotamente OOP.
Kevin
9
@RubberDuck, como a implementação do padrão já está tornando o padrão obsoleto? Ainda é o padrão de design que está sendo implementado. Conjuntos diferentes de recursos de linguagem podem levar a implementações diferentes do padrão, mas o próprio padrão ainda está lá. Os padrões existem para facilitar a comunicação, dando nomes a estratégias recorrentes que são comumente usadas. Nesse caso, as classes .NET são chamadas, o ObservableSomething<T>que facilita a compreensão de seus propósitos, porque usa o nome do padrão comumente conhecido. Um padrão é uma ideia, não uma implementação exata.
Nulo
29
@Jules: O que é um programa? Uma solução para um problema recorrente. O que é um padrão de design? Uma solução para um problema recorrente. Por que não é um programa? Porque não podemos expressá-lo como um programa. Portanto, um Padrão de Design é uma solução para um problema recorrente que deveria ser um Programa, não um Padrão de Design, mas não pode ser um Programa, porque o idioma não é expressivo o suficiente para expressar o Programa. Exemplo: não muito tempo atrás, "Chamada de sub-rotina" era um padrão de design! Atualmente, é um recurso de idioma.
Jörg W Mittag
61

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.
Jerry Coffin
fonte
2
"... mas o que realmente torna um programa interessante é como ele é diferente de outros programas." Concordo plenamente, mas para isso você precisa primeiro fazer a mesma parte, talvez eles sejam diferentes por algum aspecto trivial. Se você relaxar um pouco a necessidade de nomear e identificar padrões, estou convencido de que vemos padrões quase em todos os lugares. Só que eles quase nunca vêm em sua forma pura, mas sempre são mais ou menos adaptados ao problema em questão.
Trilarion
5
Resposta muito boa.
Robert Harvey
4
@ Trilarion: Ah, eu sei que essas partes do código precisam ser escritas. Eles são um pouco como, digamos, os pneus do seu carro. Você praticamente precisa de pneus para dirigir - mas a maioria das pessoas ainda mal conhece a marca de pneus no carro. Isso está pedindo que eles aprendam terminologia especial para um pneu com ranhuras diagonais assimétricas. Quem sabe - eles podem ter salvado minha vida uma vez, mas ainda não passo minha vida aprendendo nomes para eles.
Jerry Coffin
3
@DavidRicherby: Ok, então vamos usar uma versão "do lado do produtor" da analogia. Importa que John, que cria pneus para a Goodyear, use uma palavra para esse tipo de ranhura, mas Pierre, que trabalha na Michelin, usa uma palavra totalmente diferente? Importa que um use uma palavra referente apenas à ranhura, mas a outra uma palavra referente a um pneu completo com ranhuras horizontais em um lado do centro e ranhuras diagonais no outro?
Jerry Coffin
2
@immibis: eu diria que sim, eles falharam. Eu diria que há menos de meia dúzia de padrões que a maioria dos programadores reconhece. Singleton é bem conhecido, mas na verdade apenas raramente aplicável (na melhor das hipóteses). O nome "Factory" era de uso comum muito antes de "padrões" veio (eu me lembro o seu uso no final dos anos 1970 ou muito início dos anos 1980). Os padrões deveriam formar um vocabulário, mas atualmente eles são parecidos com o meu vocabulário em grego - o suficiente para (possivelmente) me meter em problemas, mas certamente não o suficiente para pedir um cardápio, muito menos manter uma conversa significativa.
Jerry Coffin
35

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.

Siphor
fonte
2
Pessoalmente, de alguma forma, gosto muito dessa ideia. Mas, então, o código deve ser legível por humanos e pessoas como padrões. Os padrões nos ajudam a encontrar o caminho de volta. A remoção de todos os padrões do nosso código o tornará ilegível.
Frank Puffer
2
@Frank Eu acho que de onde o PG está vindo é que um padrão é um 'cheiro' de uma função subjacente que você pode abstrair, e o fato de você não o ter colocado em uma função ou macro é o que está causando a repetição - como se você não tivesse uma String.replacefunção, poderia imaginá-la aparecendo como um padrão, mas é melhor escrevê-la uma vez, em vez de continuar a reimplementá-la. Concorda que, se você não nomear essas coisas corretamente seria torná-lo mais difícil de ler, mas quando é bem feito, código lê mais declarativa IMO (por exemplo, o getOrElseestilo de mônadas opção vs verificação null)
anotherdave
11
A citação de Paul Graham era sobre manter suas soluções SECA, o que é diferente da idéia do "padrão" do GoF. A idéia do GoF era dar nomes às soluções mais usadas. Já estávamos fazendo isso muito antes de o GoF publicar seu livro. Por exemplo, posso dizer ao meu colega de trabalho que vou usar uma fila e meu colega imediatamente sabe do que estou falando, sem precisar explicar os detalhes do que uma fila faz ou como funciona. Mas, veja a excelente resposta de Michael Borgwardt, acima.
Solomon Slow
10
Na minha opinião, esta resposta entende mal o que são padrões. Um padrão de design é uma solução frequentemente encontrada para um problema comum. Não é uma duplicação de código. Diga, faça um iterador. Você resolve o problema de abstrair o contêiner para poder percorrer os elementos dentro dele, independentemente de qual seja o contêiner. Assim, você cria uma classe de iterador que faz isso para cada um de seus contêineres e os faz implementar uma interface comum. O que é abstrato aqui? Um iterador já é uma abstração. E, é claro, é implementado de maneira diferente para todos os contêineres, sem duplicação de código.
Malcolm
3
A parte principal da citação de Graham é que estou gerando manualmente as expansões de alguma macro que preciso escrever. Isso faz referência especificamente às macros do Lisp. Há tanta abstração que se pode fazer sem macros.
Bart van Nierop
13

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

qwerty_so
fonte
11
Certo, os padrões só podem funcionar se não houver muitos deles. Mas por que os do GoF ainda são os mais populares? Alguns deles agora são considerados antipadrão por muitas pessoas (Singleton, Builder, etc.). Isso deve abrir espaço para padrões novos e mais úteis sem aumentar o número total.
Frank soprador
2
Eu acho que é como os 10 mandamentos. A fonte é de apenas dois caracteres distância (GOF, GOE, GOD) xD
qwerty_so
9
Sim, e às vezes parece que a engenharia de software moderna se relaciona com o GoF, como os escolásticos medievais se relacionam com Aristóteles.
Frank Puffer
11

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.

Jared Smith
fonte
10

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.

user207421
fonte
Ainda é triste se isso resultou nessa discussão (e tudo o que implica)
r3wt
11
@ r3wt Não sequencial . O que eu disse é triste é a fraqueza do setor de TI em pensar que todo novo desenvolvimento será a mítica bala de prata e, aliás, por destruir alguns de seus próprios trabalhos anteriores.
user207421
2
olhe para ele de uma perspectiva diferente. Não é triste para mim ler sua resposta, aprendendo a não repetir o erro. portanto, o que você dá como certo é realmente muito útil para os outros.
R3wt
6

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.

ChrisW
fonte
Sim, você pode encontrar descrições de centenas de padrões se procurá-los. Mas nada disso parece ser tão popular quanto os do GoF.
Frank soprador
Foi porque eu gostei de ler o livro do GoF que li mais (livros) quando eles foram publicados (mais tarde).
ChrisW
11
@FrankPuffer Aposto que os padrões são populares, mesmo que os nomes não sejam.
dcorking
5

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

Ian
fonte
3

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
akuhn
fonte
Por que você está me recusando? Por favor, explique em um comentário para que eu possa melhorar a resposta.
akuhn
3

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

lud1977
fonte
Bom ponto, porém duvido que muitas pessoas entendam o livro (ou padrões em geral) dessa maneira.
Frank soprador
@ lud1977 se não registramos a história, o que impede o futuro de cair nas mesmas armadilhas? portanto, sempre deve ser gravado. não é inútil.
R3wt
2

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.

iluwatar
fonte
-1

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 .

Tim
fonte
-2

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.

Marut Singh
fonte