Existe design patterns para o paradigma funcional?

johnny quest:

A gigantesca maioria dos padrões de projetos são voltados para o paradigma orientado ao objeto,
mas será que existem outros padrões voltados especificamente para o ambiente funcional ?

Se você tem duas opções para se fazer a mesma coisa, uma delas será um pattern.

A única vantagem é que linguagens funcionais geralmente te dão mais abstração, o que permite que você escreva o pattern uma única vez no código todo.

Obrigado por todas as respostas.

Realmente não deve existir ainda nenhum catalogo de design patterns específicos para o paradigma funcional.

Design Patterns são gambiarras para se trabalhar ao redor de uma limitação, e isso depende da linguagem.

Por exemplo, em Javascript não é possível usar herança. Logo se você quiser criar uma hierarquia de componentes precisará usar um pattern ou uma biblioteca que empregue esse pattern. Isso para simular uma feature que em outras linguagens é “de graça”.

Isso parece ridículo, afinal de contas, se essa feature é necessária então porque não utilizar uma linguagem que a disponibilize?

Toda Design Pattern pode ser evitada simplesmente escolhendo-se a ferramenta correta para se trabalhar.

Existem catálogos de patterns sim:
http://web.cecs.pdx.edu/~antoy/flp/patterns/

Patern não tem a ver com limitações da linguagem, e sim, com as melhores maneiras de se resolver coisas. Qualquer limguagem que te duas opções para a mesma coisa terá um pattern.

E sim, existem patterns para se tratar de limitações, mas eles não são regra e essa condição não define um pattern.

ViniGodoy:

Patern não tem a ver com limitações da linguagem, e sim, com as melhores maneiras de se resolver coisas. Qualquer limguagem que te duas opções para a mesma coisa terá um pattern.

Não, não terá.

Em algumas linguages você pode expressar o que é necessário direto na linguagem, ou extendê-la com novas construções sintáticas afim de desempenhar um determinado papel. Design Pattern é repetição de código. E isso só existe em linguagens mais limitadas.

Aqui está um texto interessando que se aplica a isso: http://paulgraham.com/avg.html

Programmers get very attached to their favorite languages, and I don’t want to hurt anyone’s feelings, so to explain this point I’m going to use a hypothetical language called Blub. Blub falls right in the middle of the abstractness continuum. It is not the most powerful language, but it is more powerful than Cobol or machine language.

And in fact, our hypothetical Blub programmer wouldn’t use either of them. Of course he wouldn’t program in machine language. That’s what compilers are for. And as for Cobol, he doesn’t know how anyone can get anything done with it. It doesn’t even have x (Blub feature of your choice).

As long as our hypothetical Blub programmer is looking down the power continuum, he knows he’s looking down. Languages less powerful than Blub are obviously less powerful, because they’re missing some feature he’s used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn’t realize he’s looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub.

When we switch to the point of view of a programmer using any of the languages higher up the power continuum, however, we find that he in turn looks down upon Blub. How can you get anything done in Blub? It doesn’t even have y.

By induction, the only programmers in a position to see all the differences in power between the various languages are those who understand the most powerful one. (This is probably what Eric Raymond meant about Lisp making you a better programmer.) You can’t trust the opinions of the others, because of the Blub paradox: they’re satisfied with whatever language they happen to use, because it dictates the way they think about programs.

Longino, nós já tivemos essa discussão. A definição de pattern é: “In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations.” (GoF)

O conceito de design pattern ser repetição de código só existe na sua cabeça. Na verdade, o Paul Graham escreveu um texto onde ele ressaltava que alguns patterns eram ser indicativos de onde as linguagens poderiam ser melhoradas, mas claro, os amantes de linguagens funcionais e trollers como você deturparam a definição e a elevaram ao extremo.

Diferentes linguagens com diferentes recursos só terão diferentes patterns. Não adianta tentar usar o livro do GoF em LISP.
Há propostas de catálogos de patterns, como a que mostrei acima, ou a lista compilada pelo Peter Norvig, que te mostrei em outro post.

Existem catálogos de patterns sim:
http://web.cecs.pdx.edu/~antoy/flp/patterns/

Patern não tem a ver com limitações da linguagem, e sim, com as melhores maneiras de se resolver coisas. Qualquer limguagem que te duas opções para a mesma coisa terá um pattern.

ViniGodoy. Obrigado por responder a minha pergunta.
Mesmo o guj começando a ficar lotado de trolls, ainda participo no guj porque aprendo bastante com diversos usuários em vários tópicos diferentes, principalmente com o ViniGodoy.

Obrigado.

Concordo com o Longino, se você esta procurando por padrões para expressar sua solução é porque sua linguagem te deixou na mão.

Sempre existem formas mais fáceis do que usar patterns, basta procurar.

ViniGodoy:

O conceito de design pattern ser repetição de código só existe na sua cabeça. Na verdade, o Paul Graham escreveu um texto onde ele ressaltava que alguns patterns eram ser indicativos de onde as linguagens poderiam ser melhoradas, mas claro, os amantes de linguagens funcionais e trollers como você deturparam a definição e a elevaram ao extremo.

Só na sua cabeça isso é ciência. Opiniões de um grupo de fulanos valem tanto quanto a de qualquer um, pois afinal de contas são apenas opiniões.

O conceito de Design Pattern foi criado devido às limitações inerentes a linguagem C++ e mais tarde muitas outras foram criadas para o Java.

O que acontece aqui é exatamente o que Paul Graham descreveu no texto dele, você acha que Design Pattern é normal porque você só consegue pensar em “Java” ou alguma linguagem imperativa similar. Se buscasse entender outros paradigmas, veria que muitos dos problemas só existem porque a linguagem de implementação é limitada, e não por causa de algum problema intrínseco ao domínio.

Acontece que não estou me baseando nas opiniões de um grupo de fulanos, mas na definição clássica de patterns, dado pelos criadores da teoria, em sua tese de doutorado.
Na minha cabeça, isso é ciência.

A única pessoa que está dando opinião aqui é você.

Longino. Eu programo em LISP com relativa freqüência. Sei o quanto a linguagem é poderosa e capaz de abstrair conceitos, evitar repetições de código, etc.

Não existe ainda um conjunto de design patterns em LISP pelos seguintes motivos:

a) Ninguém se preocupou em fazer um levantamento tão grande e preciso quanto o GoF fez (até porque, o uso de LISP ainda é bastante restrito, se comparado ao das linguagens OO);

b) A comunidade ainda não formalizou um vocabulário, num catálogo bem aceito e descrito. Um pattern só é um pattern depois de formalizado;

Por exemplo, em boas parte dos programas lisp que já trabalhei, alguém cedo ou tarde cria uma macro ou uma função para fazer algo similar ao for each, ou mesmo ao comando for.
Ok, as macros tem nomes diferentes, ou são implementadas por mecanismos diferentes, mas são basicamente a mesma solução, para o mesmo problema.

Bastaria estudar as alternativas de macros desse tipo, pesar as vantagens e desvantagens de cada um, e formalizar uma solução que pareça ser a melhor de maneira geral. Então, você dá um nome (que poderia ser “for each pattern”) para se ter um design pattern. Isso não tem nada a ver com limitação da linguagem. É simplesmente uma formalização de uma solução padrão para um problema padrão.

Mas enfim, essa a última resposta que eu te dou, afinal, você já foi até banido do fórum por trolling, e sei lá o que veio fazer aqui novamente com seu novo usuário. Como você já começou a me atacar pessoalmente, ao dizer que eu “só consigo pensar em Java”, ao dar a entender que não sei o que é ciência, e que eu “não busco entender outros paradigmas”, dou o assunto por encerrado.

Não sei se existe essa coisa de padrões visando atender todo um PARADIGMA, OO ou funcional (GoF não é um catálogo de padrões OO em geral, mas de OO segundo linguagens baseadas em C++/Java/C#).

Apesar de não concordar com o Longino, ele tem um bom argumento quando diz que patterns podem ser um sinal de limitação da linguagem, afinal como explica o fato de que grande parte do GoF se tornar irrelevante em linguagens OO mais modernas como Ruby, Scala por exemplo?

Eu por exemplo nunca ouvi ninguém reclamar de falta de formalização de padrões nessas linguagens que por sua vez são consideradas muito mais produtivas que Java.

Mas respondendo sua pergunta sobre paradigma funcional, da uma procurada por OTP (Open Telecom Platform) que, entre outras coisas, define um conjunto de design patterns para programação concorrente, tolerante a falhas, em Erlang.

Concordo com você. Java pode ser complexo demais, mas limitado?

Uma linguagem que pode ser usada para criar programas mobile, server, desktop, TV Digital, embarcados, etc…

…não é limitado para programadores de “mercado”.

Eu nunca disse que patterns não podem ser um sinal de falha da linguagem. Um problema comum pode surgir de uma deficiência da linguagem, como é o caso do padrão Singleton. Eu só critiquei o fato dele definir padrão como uma falha da linguagem. Muitos padrões, de fato, são justamente o oposto: a linguagem dá muitos meios de resolver o problemas, e há vários trade-offs envolvidos em cada um (muitos nem sempre óbvios). Fábricas, listeners, são justamente esse caso. As linguagens dão diversas formas de fazer essas coisas, e uma delas acaba se provando a melhor com o tempo e a experiência.

E, claro, creio que será possível implementar mecanismos nas linguagens para automatizar, ou facilitar alguns padrões.

vargas:

Eu por exemplo nunca ouvi ninguém reclamar de falta de formalização de padrões nessas linguagens que por sua vez são consideradas muito mais produtivas que Java.

Mas respondendo sua pergunta sobre paradigma funcional, da uma procurada por OTP (Open Telecom Platform) que, entre outras coisas, define um conjunto de design patterns para programação concorrente, tolerante a falhas, em Erlang.

Isso porque a cultura OO é muito rica, se comparado a das linguagens funcionais. Por mais legal que o LISP e o paradigma funcional sejam (e eu acho ele muito legal) ele ainda está muito aquém da popularidade da OO. Com isso, há menos literatura e menos demanda. É difícil ver aplicações grandes integralmente desenvolvidas na linguagem. Muitas são aplicações para rodar sob funções específicas, ou scripts integrados à outra linguagem.

ViniGodoy:

Eu nunca disse que patterns não podem ser um sinal de falha da linguagem. Um problema comum pode surgir de uma deficiência da linguagem, como é o caso do padrão Singleton. Eu só critiquei o fato dele definir padrão como uma falha da linguagem. Muitos padrões, de fato, são justamente o oposto: a linguagem dá muitos meios de resolver o problemas, e há vários trade-offs envolvidos em cada um (muitos nem sempre óbvios). Fábricas, listeners, são justamente esse caso. As linguagens dão diversas formas de fazer essas coisas, e uma delas acaba se provando a melhor com o tempo e a experiência.

Isso não explica porque essa cultura de padrões não existe em linguagens OO mais moderna.

ViniGodoy:

Isso porque a cultura OO é muito rica, se comparado a das linguagens funcionais. Por mais legal que o LISP e o paradigma funcional sejam (e eu acho ele muito legal) ele ainda está muito aquém da popularidade da OO. Com isso, há menos literatura e menos demanda. É difícil ver aplicações grandes integralmente desenvolvidas na linguagem. Muitas são aplicações para rodar sob funções específicas, ou scripts integrados à outra linguagem.

Desculpa, mas você está trolando? Assim fica difícil te levar a sério… linguagens funcionais estão em todo lugar. Amazon usa linguagens funcionais em praticamente todos seus serviços, projetos opensource como CouchDB, RIAK, RabbitMQ, isso sem falar no Facebook, WhatsApp, moreladores 3D (Wings3D).

Você quis dizer linguagens OO ou linguagens funcionais?

Não, não estou trolando. Não falei que não existem projetos com linguagens funcionais, nem que não existem projetos grandes, ou que essas linguagens são ruins.

Eu escrevi que comparado ao número de projetos OO, o uso de linguagens funcionais ainda é muito restrito. E, como reflexo, há menos faculdades ensinando programação funcional (e, quando ensinam, geralmente é em uma matéria só), e há menos engenheiros de software preocupados em desenvolver métodos e técnicas de desenvolvimento que considerem linguagem funcional como seu mainstream.

Creio que haja boas chances de um catálogo de padrões não existir simplesmente porque ninguém ainda teve iniciativa de procurar empresas que desenvolvam fortemente com linguagens funcionais, estudar os códigos que eles desenvolvem e compilar o catálogo. Além disso, creio que mesmo que alguém fizesse isso, esse catálogo não teria a importância que teve o GoF, pois o uso de linguagens funcionais não é regra, mas sim exceção. Acho que é a mesma razão pelo qual não ouvimos falar de “análise de sistemas funcionais”, ou não temos algo como uma UML para linguagens funcionais.

Eu sinceramente gostaria que isso se invertesse no futuro. Gosto muito de programar em linguagens funcionais, e não ficaria nem um pouco triste se elas tomassem o lugar das tecnologias OO de hoje em dia.

Você quis dizer linguagens OO ou linguagens funcionais?

Eu disse OO mesmo. Java e C++ são as únicas que divulgam padrões de software como solução. Python, Ruby e Scala são mais diretas.

ViniGodoy:

Eu escrevi que comparado ao número de projetos OO, o uso de linguagens funcionais ainda é muito restrito.

Não é restrito. Citei vários exemplos de projetos reais e de alto nível que usam linguagens funcionais.

No que diz respeito a Lisp eu concordo com você, é uma linguagem arcaica e pouco usada.

Criei esse tópico faz alguns meses, e quando abri ele achava que o GOF somente tinha sua definição no mundo OO, e por isso perguntei
se existiam padrões para o paradigma funcional,

mas passado uns meses e procurando mais achei esses artigos de um arquiteto da ThoughtWorks explicando como o GOF se aplica e fica até mais elegante no paradigma funcional do que no paradigma OO.

http://imasters.com.br/artigo/24360/design/pensamento-funcional-padroes-de-design-funcional-parte-01

http://imasters.com.br/artigo/24415/java/pensamento-funcional-padroes-de-design-funcional-parte-2

http://imasters.com.br/artigo/25227/java/pensamento-funcional-padroes-de-design-funcional-parte-03

Somente estou compartilhando isso para enriquecer o tópico.

Longino:

ViniGodoy:

O conceito de design pattern ser repetição de código só existe na sua cabeça. Na verdade, o Paul Graham escreveu um texto onde ele ressaltava que alguns patterns eram ser indicativos de onde as linguagens poderiam ser melhoradas, mas claro, os amantes de linguagens funcionais e trollers como você deturparam a definição e a elevaram ao extremo.

Só na sua cabeça isso é ciência. Opiniões de um grupo de fulanos valem tanto quanto a de qualquer um, pois afinal de contas são apenas opiniões.

O conceito de Design Pattern foi criado devido às limitações inerentes a linguagem C++ e mais tarde muitas outras foram criadas para o Java.

O que acontece aqui é exatamente o que Paul Graham descreveu no texto dele, você acha que Design Pattern é normal porque você só consegue pensar em “Java” ou alguma linguagem imperativa similar. Se buscasse entender outros paradigmas, veria que muitos dos problemas só existem porque a linguagem de implementação é limitada, e não por causa de algum problema intrínseco ao domínio.

A prova de que um pattern não é limitação da linguagem está na implementação de Singleton em Scala. A linguagem dá suporte ao padrão com a keyword “object”. Porque seria uma limitação da linguagem ? Entendam que esse argumento não faz sentido algum. O padrão é usado porque ele resolve um problema e é muito usado se resolve um problema comum. Mas “problema” aqui, não significa “defeito da linguagem” e sim “desafio em design orientado a objeto”. A implementação de Singleton em scala vai mais além e até ajuda a simplificar a linguagem (não ha static em scala, porque sempre é possivel associar um Singleton a cada classe). Outro padrão que scala oferece suporte melhor que java é o builder. Não tanto à criação do builder, mas ao seu uso. O mesmo acontece em groovy. Groovy ainda oferece suporte nativo a Decorator e Proxy, mas não a singleton. Nada disto significa que a linguagem é melhor ou pior.
Java também oferece uma forma nativa para implementar singleton (enum), mas isso não significa que haja uma problema na linguagem java.

O ponto é que se uma linguagem fornece um bom suporte a muito padrões então a programação é mais fácil (Scala se aproveita disto muito bem)

Padrões são solução iguais para desafio recorrentes no design OO, não na implementação (seja em que linguagem for). Discutir que os design patterns demonstram problemas na linguagens é pointless. Interessante é discutir é como os padrões , quando suportados pelas linguagens, as tornam melhores e a programação mais simples.
O texto citado nem sequer aborda este tema. Ele fala genericamente de “features” da linguagem. Isso pode ser qualquer coisa.

Ah! e javascript sim tem suporte a herança, só não tem suporte a clases [1], [2].

Você quis dizer linguagens OO ou linguagens funcionais?

Eu disse OO mesmo. Java e C++ são as únicas que divulgam padrões de software como solução. Python, Ruby e Scala são mais diretas.

Impressão sua.
O Ruby é baseado na variação do padrão Prototype conhecido como Metaclass ( que a oracle quer para o java 9).
Vc tem este padrão em java (Apache commnons DynaType) mas ninguem usa depois do fiasco do struts 1 e a criação de anotações e a turbinada nas jvm que tornou o reflection de uso comum ( a oracle quer melhorar a performance do refelction para o java 8 e seguintes , porque vc terá um operador novo (: para obter SAMs a partir de métodos que já existem)
Em scala é comum falar de monoids e monads . Porquê estes padrões não são referidos em Java ?
Porque não são necessários/utilizados. A partir do Java 8 vai ser mais familiar o conceito expresso pelos monoids e monads porque a programação poderá ser mais funcional. Estilos de programação levam a certos padrões especiais.

Padrões sim existem em outras linguagens. Existem até em coisas que não são linguagens (arquitetura, por exemplo, de onde vem o conceito original).
Design PAtterns, em especifico advém de Design e são ferramentas para o Design. além disso forma uma linguagem. Se eu disse para outro programador que o sistema será baseado me produtor-consumidor, ele saberá o que isso significa. duas palavras para referir um conceito recorrente e comum, mas com implementação arbitráriamente complexa dependendo do nivel e do que é produzido. A classe Executor usa este padrão, assim como o novo framework Fork/Join.

A cultura dos padrão - como vc colocou - é isso mesmo, uma cultura. E como todas as culturas é preciso entendê-la e estudá-la. E claro, respeitá-la, mesmo que seja diferenta da sua.

Longino:

Design Patterns são gambiarras para se trabalhar ao redor de uma limitação, e isso depende da linguagem.

Por exemplo, em Javascript não é possível usar herança. Logo se você quiser criar uma hierarquia de componentes precisará usar um pattern ou uma biblioteca que empregue esse pattern. Isso para simular uma feature que em outras linguagens é “de graça”.

Isso parece ridículo, afinal de contas, se essa feature é necessária então porque não utilizar uma linguagem que a disponibilize?

Toda Design Pattern pode ser evitada simplesmente escolhendo-se a ferramenta correta para se trabalhar.

A última coisa que alguém que compra a idéia de “soluções reutilizáveis” está procurando é ter que avaliar linguagens caso-a-caso conforme a necessidade.

Você quis dizer linguagens OO ou linguagens funcionais?

Não, não estou trolando. Não falei que não existem projetos com linguagens funcionais, nem que não existem projetos grandes, ou que essas linguagens são ruins.

Eu escrevi que comparado ao número de projetos OO, o uso de linguagens funcionais ainda é muito restrito. E, como reflexo, há menos faculdades ensinando programação funcional (e, quando ensinam, geralmente é em uma matéria só), e há menos engenheiros de software preocupados em desenvolver métodos e técnicas de desenvolvimento que considerem linguagem funcional como seu mainstream.

Creio que haja boas chances de um catálogo de padrões não existir simplesmente porque ninguém ainda teve iniciativa de procurar empresas que desenvolvam fortemente com linguagens funcionais, estudar os códigos que eles desenvolvem e compilar o catálogo. Além disso, creio que mesmo que alguém fizesse isso, esse catálogo não teria a importância que teve o GoF, pois o uso de linguagens funcionais não é regra, mas sim exceção. Acho que é a mesma razão pelo qual não ouvimos falar de “análise de sistemas funcionais”, ou não temos algo como uma UML para linguagens funcionais.

Eu sinceramente gostaria que isso se invertesse no futuro. Gosto muito de programar em linguagens funcionais, e não ficaria nem um pouco triste se elas tomassem o lugar das tecnologias OO de hoje em dia.

Não perca o seu tempo discutindo com Longino. Discuta com alguém que pelo menos possa agregar algo de útil ao fórum. Esse sujeito é um zero a esquerda(com mais zeros somados aos seus fakes).

Você quis dizer linguagens OO ou linguagens funcionais?

Eu disse OO mesmo. Java e C++ são as únicas que divulgam padrões de software como solução. Python, Ruby e Scala são mais diretas.

Impressão sua.
O Ruby é baseado na variação do padrão Prototype conhecido como Metaclass ( que a oracle quer para o java 9).
Vc tem este padrão em java (Apache commnons DynaType) mas ninguem usa depois do fiasco do struts 1 e a criação de anotações e a turbinada nas jvm que tornou o reflection de uso comum ( a oracle quer melhorar a performance do refelction para o java 8 e seguintes , porque vc terá um operador novo (: para obter SAMs a partir de métodos que já existem)
Em scala é comum falar de monoids e monads . Porquê estes padrões não são referidos em Java ?
Porque não são necessários/utilizados. A partir do Java 8 vai ser mais familiar o conceito expresso pelos monoids e monads porque a programação poderá ser mais funcional. Estilos de programação levam a certos padrões especiais.

Padrões sim existem em outras linguagens. Existem até em coisas que não são linguagens (arquitetura, por exemplo, de onde vem o conceito original).
Design PAtterns, em especifico advém de Design e são ferramentas para o Design. além disso forma uma linguagem. Se eu disse para outro programador que o sistema será baseado me produtor-consumidor, ele saberá o que isso significa. duas palavras para referir um conceito recorrente e comum, mas com implementação arbitráriamente complexa dependendo do nivel e do que é produzido. A classe Executor usa este padrão, assim como o novo framework Fork/Join.

A cultura dos padrão - como vc colocou - é isso mesmo, uma cultura. E como todas as culturas é preciso entendê-la e estudá-la. E claro, respeitá-la, mesmo que seja diferenta da sua.

Acho que essa foi a pérola do ano. Padrões ser considerado por alguns como falha em linguagem e não como “a melhor maneira”(aliás como o objetivo de qualquer tipo de engenharia é) para se resolver um problema.

Só poderia sair de gente que discute linguagem de programação como time de futebol.

juliocbq:

Acho que essa foi a pérola do ano. Padrões ser considerado por alguns como falha em linguagem e não como “a melhor maneira”(aliás como o objetivo de qualquer tipo de engenharia é) para se resolver um problema.

Só poderia sair de gente que discute linguagem de programação como time de futebol.

Do ponto de vista do design, o destino de todo padrão de sucesso é ser absorvido. Não faz muito sentido uma cultura de padrões de successo que vive à parte da linguagem.

A não ser claro, que a linguagem esteja estagnada ou é incapaz de ser estendida para oferecer a funcionalidade sem exigir grandes mudanças no projeto original.

Os design patterns existem porque não há como qualquer linguagem de programação seguir a criatividade dos desenvolvedores. Alguém acha uma solução incrível, programa isso na linguagem que conhece. Daí alguém chega, descobre que está escrevendo linhas e linhas de código que poderia ser irrelevante, e resolve criar uma linguagem ou framework em que aquele padrão está implícito.

No momento em que alguém resolve utilizar o recurso X da linguagem + o recurso Y, sempre da mesma maneira, está usando design pattern sem saber. Design pattern tem a ver com utilizar de novo em projetos diferentes, conceitos que deram certo em outros projetos.

Um design pattern é, antes de mais nada, uma opção. A linguagem deixa fazer determinada coisa do jeito X, do jeito Y e do jeito Z. Mas a equipe opta por utilizar o jeito Z. Pronto, design pattern.

Outro ponto. Um design pattern é, antes de tudo, um rótulo de determinada solução. Dois arquitetos podem falar entre si algo como “vamos utilizar o Strategy Pattern para resolver isto, e o Static Factory para resolver aquilo”. E os dois se entendem. Se não souberem design patterns, eles vão ter que sentar em uma sala por horas a fio para se entenderem.

Até aqui eu concordo com vc.

abmpicoli:

No momento em que alguém resolve utilizar o recurso X da linguagem + o recurso Y, sempre da mesma maneira, está usando design pattern sem saber. Design pattern tem a ver com utilizar de novo em projetos diferentes, conceitos que deram certo em outros projetos.

Isso pode ter a ver com design pattern, mas certamente não é o que define um padrão como sendo de sucesso.

Um padrão de sucesso é aquele que serve o meu problema específico, e não o que é mais genérico.

abmpicoli:

Outro ponto. Um design pattern é, antes de tudo, um rótulo de determinada solução. Dois arquitetos podem falar entre si algo como “vamos utilizar o Strategy Pattern para resolver isto, e o Static Factory para resolver aquilo”. E os dois se entendem. Se não souberem design patterns, eles vão ter que sentar em uma sala por horas a fio para se entenderem.

O que tenho observado é o contrário. Quando o pattern é absorvido a comunicação se da usando o idioma da linguagem ou do framework, e não de uma nomenclatura à parte.

Inclusive é isso que possibilita eventualmente o usuário usar o padrão sem saber que está usando.

tionil:

Realmente, apenas utilizar recursos X + Y de uma linguagem repetidamente não constitui um design pattern. Para se tornar um design pattern tem que haver uma rotulação (por exemplo, “Static Factory”), uma conscientização e expressão do problema sendo resolvido + a forma de se resolver.

tionil:

abmpicoli:

Outro ponto. Um design pattern é, antes de tudo, um rótulo de determinada solução. Dois arquitetos podem falar entre si algo como “vamos utilizar o Strategy Pattern para resolver isto, e o Static Factory para resolver aquilo”. E os dois se entendem. Se não souberem design patterns, eles vão ter que sentar em uma sala por horas a fio para se entenderem.

O que tenho observado é o contrário. Quando o pattern é absorvido a comunicação se da usando o idioma da linguagem ou do framework, e não de uma nomenclatura à parte.

Inclusive é isso que possibilita eventualmente o usuário usar o padrão sem saber que está usando.

Além disto, conhecer os design patterns utilizados nos frameworks auxiliam no entendimento dos frameworks que o implementam. Do conhecimento específico a determinada linguagem se passa ao genérico.

Uma linguagem expressiva é aquela que permite o desenvolvedor resolver o problema usando “apenas” os recursos da linguagem, sem que para isso tenha que depender de convenções culturais sobre boas práticas.

Saber como um padrão nasce é ótimo, mas só é útil pra quem é pago pra colecionar padrões e depois escrever artigos sobre eles.

A palavra chave aqui é “recursos similares”.

Como estamos falando de OO x funcional, padrões GoF são inúteis (pra não dizer nocivos ao programador tentando aprender um paradigma não-OO).

Para linguagens funcionais existem outros patterns, diferentes.

A vantagem, como já falei em janeiro, é que essas linguagens são mais expressivas, então provavelmente você poderá automatiza-los uma vez só, no início do desenvolvimento. Como a comunidade desse tipo de linguagem é consideravelmente menor que a comunidade OO, não é de surpreender que não existem livros sobre isso.

Há catálogos na internet, porém, um deles criado inclusive pelo próprio Peter Norvig:
http://norvig.com/design-patterns/
http://web.cecs.pdx.edu/~antoy/flp/patterns/

ViniGodoy:

Para linguagens funcionais existem outros patterns, diferentes.

A vantagem, como já falei em janeiro, é que essas linguagens são mais expressivas, então provavelmente você poderá automatiza-los uma vez só, no início do desenvolvimento. Como a comunidade desse tipo de linguagem é consideravelmente menor que a comunidade OO, não é de surpreender que não existem livros sobre isso.

Há catálogos na internet, porém, um deles criado inclusive pelo próprio Peter Norvig:
http://norvig.com/design-patterns/
http://web.cecs.pdx.edu/~antoy/flp/patterns/

Os padrões GoF foram publicados há bastante tempo, em 1994. E não por uma comunidade, mas por Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides.

Pessoalmente não acho que a comunidade funcional hoje esteja tão atrás assim da comunidade OO em 94.

E eles são parte da comunidade dos programadores OO.
Em momento nenhum falei que os padrões GoF são de milhares de programadores, ou de autoria indefinida.

Talvez não esteja mesmo. Aí é só uma questão de tempo até sair algum trabalho como o do GoF.
Os próprios artigos que apontei são nesse sentido.

ViniGodoy:

E eles são parte da comunidade dos programadores OO.
Em momento nenhum falei que os padrões GoF são de milhares de programadores, ou de autoria indefinida.

Devo ter entendido errado então, mas deu a entender que o tamanho da comunidade fosse relevante para o trabalho de um livro.

É estranho porque existe mais de 1 livro sobre padrões em linguagens funcional e só neste tópico foram citados vários links.

Vini, nem perda seu tempo respondendo trolls nesse tópico.

Os caras entram com diversas contas diferentes no guj, conversam entre si, NÃO AGREGAM NADA AO TÓPICO, não
leem nada e não aprendem nada sobre o que foi postado e somente poluem com opinião pessoal igual time de futebol.