Então, “os padrões de design estão faltando recursos de idioma”? [fechadas]


12

Eu vi, aqui nos programadores, a resposta para essa pergunta: como o pensamento sobre padrões de design e práticas de OOP muda em linguagens dinâmicas e de tipo fraco? Lá encontrei um link para um artigo com um título franco: Os padrões de design estão faltando recursos de linguagem . Mas onde encontrei trechos que para mim pareciam muito cativantes e que provavelmente podem ser verificados com base na experiência, pois há um incentivo para isso, como:

PaulGraham disse que "Peter Norvig descobriu que 16 dos 23 padrões no Design Patterns eram 'invisíveis ou mais simples' no Lisp".

ou outra frase que confirme o que vi recentemente com pessoas tentando simular aulas em JavaScript:

Obviamente, ninguém nunca fala do padrão de "função", ou padrão de "classe", ou de várias outras coisas que consideramos um dado adquirido, porque a maioria dos idiomas os fornece como recursos internos. OTOH, programadores em uma linguagem puramente PrototypeOriented? pode ser conveniente simular classes com protótipos ...

Também estou levando em consideração que os padrões de design são uma ferramenta de comunicação . Porque mesmo com minha experiência limitada participando da criação de aplicativos, posso ver como um antipadrão ( ineficaz e / ou contraproducente ), por exemplo, forçando uma pequena equipe PHP a aprender padrões GoF para aplicativos de intranet de pequeno a médio porte. Estou ciente de que escala, escopo e propósito podem determinar o que é eficaz e / ou produtivo, mas ainda não consegui encontrar uma visão geral técnica sobre isso.

Vi pequenas aplicações comerciais que combinavam funcionalidade com OOP e ainda eram mantidas, e não sei se muitos precisariam, por exemplo, em python para escrever um singleton, mas para mim um módulo simples faz a mesma coisa.

Portanto, existem estudos, artigos exaustivos ou outra forma de exposição que leva em consideração padrões de design versus soluções alternativas e maneiras mais simples de fazer isso, ou substituições por recursos de linguagem?


16
Seria um erro aceitar qualquer coisa que Paul Graham diga sobre o assunto das linguagens de programação como "objetiva e factual".
Mason Wheeler

5
Não costumo discordar de Paul Graham, mas @MasonWheeler está certo, os evangelistas são ótimos por muitas razões, mas não por sua objetividade.
Jimmy Hoffa

3
@ JimmyHoffa: Não são "evangelistas" em geral. Discordo da longa história de Graham de publicar material ridículo que freqüentemente contradiz a si mesmo ou a suas fontes e tenta fazer com que tudo pareça consistente. Não importa o que você está defendendo, é uma maneira horrível de fazer isso, e é um pouco assustador para mim que as pessoas realmente o escutem.
Mason Wheeler

5
Seria bom para ver alguns estudos, mas se você já usou modernas linguagens funcionais - você já sabe como obsoleto GOF padrões de design são, e não há necessidade de número de provar isso mais . (Porém, eles foram importantes em 1990, sem dúvida).
C69

3
@ DanielB, todo paradigma específico falhará, porque a realidade é muito mais complexa do que qualquer paradigma jamais poderia ser. Portanto, todo e qualquer problema merece seu próprio modelo e paradigma específico de domínio.
SK-logic

Respostas:


10

Não conheço nenhuma discussão ou estudo aprofundado que leve em conta todas essas coisas.

Dito isto, todo o argumento de "padrões de design está apenas corrigindo recursos ausentes nas linguagens OO" é um pouco tênue, na minha opinião. Sim, alguns padrões de design são exatamente isso, eles preenchem uma lacuna comum que nem existe em alguma outra linguagem X. Esses são tipicamente seus padrões de design mais simples e de baixo nível, como alguns / muitos dos originais do livro GoF.

Mas os padrões de design vão muito além daqueles simples, e chamá-los de recursos de linguagem ausentes amplia a imaginação. Dê uma olhada no catálogo de padrões de aplicativos corporativos de Fowler e pense em como seria se todos fizessem parte da definição principal de uma linguagem. Eu acho que você acabaria com uma linguagem específica de domínio ( DSL ) para aplicativos corporativos (e muito complexa).

Então é isso mesmo: os padrões de design são uma maneira de apresentar soluções reutilizáveis ​​para problemas específicos (que geralmente são aplicados em uma linguagem genérica para todos os fins). É aqui que a comunicação também entra. Se você me disser "usamos o Active Records", já sei bastante sobre seu aplicativo, sem gastar minutos discutindo quais são as várias abordagens. Então, sim, os padrões de design corrigem falhas na especificação da linguagem. Isso é tudo o que eles fazem? Não - não por um longo tiro.

Editar:

De certa forma, o que estou dizendo é que os padrões permitem que os profissionais de OO pensem em um nível superior e quase construam um tipo de DSL para seu ambiente, mantendo-se dentro da sintaxe de sua linguagem. E sim, eu vi o que acontece quando você os aplica em qualquer lugar (consulte: AbstractSingletonProxyFactoryBean , sim, ele existe) ou acha que eles são algum tipo de bala de prata. O ponto é que, embora demorem muito tempo para se sentirem realmente confortáveis, eles devem realmente diminuir a complexidade, tornando as coisas previsíveis / compreensíveis em alto nível. Isso é muito diferente de ser um kit de correção para as falhas do seu idioma.

Edição 2 - adicionado o contra-exemplo AbstractSingletonProxyFactoryBean para zombar dos padrões. Para ser completamente justo, quando visto sob uma luz de AOP, mesmo esse contra-exemplo é defensável.


(+1) e aceite porque você restringiu minha pesquisa nos padrões de DSL e de aplicativo. Muito atencioso, e você pode expandir ou vincular o leitor, talvez entre parênteses, pelo menos uma das siglas DSL, suponho que significa linguagem específica do domínio.
Eduard Florinescu 21/09/12

@EduardFlorinescu obrigado, atualizei com links para DSL.
Daniel B

Também encontrei este artigo confirmando parte de sua resposta neste caso com Groovy ibm.com/developerworks/java/library/j-eaed7/index.html
Eduard Florinescu

1
@ EduardFlorinescu isso é muito interessante, embora eu não estivesse apenas me referindo especificamente ao padrão de intérpretes; pelo contrário, quis dizer que muitos padrões podem ser bastante específicos do domínio e se tornar quase idiomáticos para os desenvolvedores desse domínio. Nesse sentido, eles se tornam um tipo de DSL e não exigem muito esforço para entender e usar. Por exemplo, quando leio um padrão de comando (um exemplo específico que não seja de domínio), sei qual código padrão eu posso ignorar com segurança e não é preciso muito esforço. Mas obrigado pelo link interessante, no entanto.
Daniel B
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.