Onde estão todos os padrões de design de programação funcional? [fechadas]

75

A literatura de programação OO está cheia de padrões de design. A maioria dos livros sobre programação orientada a objetos dedica um ou dois capítulos para projetar padrões como fábricas e decoradores. Então, quais são os padrões equivalentes nas linguagens funcionais e por que alguém ainda não escreveu um livro sobre eles? Existe algo especial nas linguagens funcionais que evita a necessidade de padrões de design?

books design-patterns functional-programming

— davidk01
fonte

6

Existem padrões de design definitivamente funcionais - tomar memoisation ou mônadas por exemplo - Eu também estou querendo saber se alguém reuniu-los em um só lugar embora ...

— FinnNk

2

FinnNk Monad é mais de um tipo de classe do que um padrão de design ^ _ ^

— alternativa

Para Haskell, Gabriel Gonzalez tem alguns posts, por exemplo haskellforall.com/2012/08/the-category-design-pattern.html

— bennofs

2

infoq.com/presentations/Clojure-Design-Patterns

— boucekv

1

Reduzir mapa é um. Estou desapontado que não há uma boa lista de padrões

— Sridhar Sarnobat

48

OO e programação funcional são dois paradigmas de programação muito diferentes, e os padrões de design (DP) são uma parte significativa do design e programação de OO. DP não tem esse papel na programação funcional.

Pode-se até dizer que o DP não é necessário na programação funcional - não há coceira com a qual o DP é curado.

Alguém poderia argumentar que os padrões de design são um sinal de falta de recursos em uma linguagem de programação.
Peter Norvig descobriu que 16 dos 23 padrões do livro Design Patterns são " r invisíveis ou simples " em Lisp ou Dylan.
"Muitos padrões implicam orientação a objetos ou, geralmente, um estado mutável e, portanto, pode não ser tão aplicável em linguagens de programação funcionais, nas quais os dados são imutáveis ou tratados como tal." - http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29

— Maglob
fonte

41

Não tenho certeza se concordaria que os padrões de design não se aplicam ao FP. O FP ainda apresenta problemas comuns que são resolvidos de maneiras particulares e comuns. Problemas diferentes daqueles resolvidos no OO, mas ainda assim problemas. Eu acho que provavelmente é apenas algo que tem recebido muito menos atenção do que em OO, já que o FP é menos comum no mundo comercial no momento.

— d11wtq

22

Afirmar que o padrão de design não existe na programação funcional é desinformação. O contra-exemplo mais fácil é a mônada. Você não precisa usar a mônada na programação funcional, mas é um padrão muito comum que as pessoas seguem para facilitar a aplicação da programação de funções puras. Essa é, em essência, a definição de padrão de design.

— voidvector

3

Os padrões de design se aplicam a todas as atividades de design, seja de programação ou design de casa. De fato, os próprios conceitos de linguagens de padrões vêm da arquitetura: en.wikipedia.org/wiki/A_Pattern_Language .

— precisa saber é o seguinte

2

Hmm. Fluxos observáveis, validação ferroviária e o inferno, praticamente todas as mônadas são um padrão de design, certo?

— Chet

2

@voidvector As mônadas não são simplesmente um padrão de design. No FP, as mônadas são usadas como functores entre sistemas de tipos, e o próprio conceito vem da Teoria das Categorias, um ramo da matemática. Eles são usados para descrever um tipo particular de relacionamento entre estruturas algébricas em geral. Seria mais preciso dizer que a programação funcional é um padrão de projeto para facilitar o uso da matemática na programação.

— John Cramerus 07/07

67

Jeremy Gibbons está escrevendo o livro. Até terminar, você pode ler o blog dele, Patterns in Functional Programming . Ele recomenda ler suas postagens da mais antiga para a mais nova.

Navegue pelas publicações dele também. Ele cobre os padrões do Gang of Four em Design Patterns como programas genéricos de tipo de dados de ordem superior e descreve os padrões de programação com equações recursivas na programação de origami (dobras e desdobramentos).

— Março de Corbin
fonte

13

O fato simples é que muitos padrões OO seriam considerados expressões idiomáticas em linguagens funcionais (especialmente os padrões GoF originais). Por exemplo, o padrão Iterator (embutido em idiomas como C # agora) simplesmente não é necessário em um Lisp ou ML que possua operadores de sequência.

Muitos dos padrões que usamos nos sistemas OO estão lá para nos ajudar a tirar o "não essencial" do caminho, para que possamos focar na codificação de objetos. Em outras palavras, os padrões são soluções para as partes não interessantes do aplicativo. Devemos aproveitar os padrões para atender às necessidades comuns que já foram resolvidas anteriormente (como os padrões do Fowlers Patterns of Enterprise Application Architecture para lidar com coisas como transmissão de banco de dados ou xUnit Patterns para melhorar o teste de unidade), para que possamos focar na adição de valor comercial para a aplicação.

Tenho certeza de que, além das especificidades dos padrões GoF, existem padrões de design que também serão aplicáveis à programação funcional. O fato é que OO é o paradigma dominante. Escrever um livro de padrões direcionado a desenvolvedores funcionais ... bem, francamente, não receberá um sinal verde de um editor. É para isso que tudo se resume. Não há mercado suficiente para os Padrões Funcionais ter um número significativo de livros dedicados ao tópico.

— Michael Brown
fonte

9

Uma boa conversa (~ 45 min) sobre este tópico por Stuart Sierra:

http://www.infoq.com/presentations/Clojure-Design-Patterns

Não necessariamente vinculativo e autoritário, mas reconheci vários exemplos de minha própria experiência usando FP para análise de dados.

Exemplos escritos em Clojure, mas provavelmente aplicáveis a qualquer linguagem FP. Os nomes que ele dá aos padrões que ele cobre são:

Estado / Evento
Consequências
Acumulador
Reduzir / Combinar
Expansão Recursiva
Pipeline
Embrulho
Símbolo
Observador
Estratégia

— Aaron Johnson
fonte

6

Se você está realmente interessado em aprender, os padrões de design não precisam mais procurar, Haskell. Se você reservar um tempo para aprender o idioma da maneira mais difícil, encontrará e se familiarizar com a maioria dos padrões fundamentais - eles serão incorporados ao idioma.

Não pule mônadas. Existem várias explicações exaustivas por aí e é preciso algum esforço para que as idéias se aprofundem, mas se você continuar se conectando, eventualmente surgirá você e você ficará surpreso com quantos padrões de design podem ser usados. construir sobre essa abstração / interface.

Depois de gritar Haskell, você terá o suficiente do arsenal de FP à sua disposição para ser perigoso. O ponto é: continue assim até conseguir. Não há atalhos.

— Mario T. Lanza
fonte

-3

Na medida em que a metodologia de design do FP é projetar seus tipos para refletir com precisão o espaço do problema e a implementação deve seguir automaticamente, o equivalente ao FP de um livro sobre padrões de design é algo como as Estruturas de Dados Puramente Funcionais de Chris Okasaki .

— geekosaur
fonte

1

O livro de Okasaki é o equivalente da parte da estrutura de dados de vários livros de estrutura e algoritmos de dados, que geralmente consideram apenas a estrutura de dados mutáveis.

— AProgrammer

1

Não acho que equiparar estruturas de dados a padrões de design se encaixa bem. Não é como se os programadores de OO se esforçassem até que as definições de classe apropriadas aparecessem.

— Davidk01 3/07

Sim, o livro de Okasaki está em um nível inferior aos padrões de design.

— FinnNk