Equivalente aos princípios do SOLID para programação funcional

Eu achei os princípios do SOLID bastante úteis quando pensamos em design orientado a objetos.

Existe um conjunto semelhante / equivalente de princípios agnósticos de linguagem adaptados para programação funcional?

design-patterns functional-programming solid

— Mikera
fonte

FWIW, este foi discutido brevemente sobre SO um ano atrás

— StuartLC

DI e HOF: programmers.stackexchange.com/questions/103508/…

— paul

Este vídeo , bem como esses slides apresentar os princípios sólidos aplicada a programação funcional. Ambos usam a linguagem Clojure como exemplo, mas os princípios são válidos em outros idiomas.

— Mascip

slideshare.net/RichardWarburton/…

— Ray Tayek

veja também: A programação funcional é um superconjunto de objetos orientados?

— mosquito

Respostas:

É um pouco difícil encontrar equivalentes, mas posso tentar:

S (SRP) na função FP cria SEMPRE a mesma saída para os mesmos argumentos, isso é chamado de transparência referencial
O (OCP) no FP, existe um conceito chamado tipos de dados algébricos, veja como ele se relaciona às hierarquias de classe e que problema ambos tentam resolver ¹
O princípio da substituição de L (LSP) Liskov é contravariância ²
D (DIP) na programação funcional geral obtém abstração através da composição da função, também existem outros mecanismos com a ajuda da teoria das categorias (por exemplo, monóide ou functor), para "Injeção de Dependência" ³

— AndreasScheinert
fonte

Ainda estou pensando em como você passou do Princípio da Responsabilidade Única para a transparência referencial . Esses dois não têm relação. SRP é sobre uma função com um único objetivo. Pode ou não ser referencialmente transparente, com relação a isso.

— Goran Jovic

Ah, meu mal - eu entendi agora. São equivalentes no sentido de serem princípios e formar a mesma sigla, não no sentido de significar a mesma coisa ou coisa semelhante. Desculpe pelo voto negativo!

— Goran Jovic

Certo, é a maneira pretendida de lê-lo. Tentei descrever um mapeamento para esses termos no contexto de fp.

— AndreasScheinert

Cara, eu odeio que você não possa editar um comentário, na verdade as coisas DEVEM significar pelo menos algo semelhante.

— AndreasScheinert

Talvez funções de ordem superior possam fornecer algum tipo de injeção de dependência: você injeta uma função concreta como parâmetro em uma função genérica (de ordem superior).

— Giorgio

O SOLID também é uma boa ideia para os reinos funcionais / imperativos.

SRP - 'Apenas faça uma coisa' foi tirado da programação imperativa em primeiro lugar. Ter pequenas funções focadas é bom.

OCP - Permitir que você altere comportamentos sem modificar o código é bom. A programação funcional usa funções de ordem superior mais do que herança, mas o princípio é válido.

LSP - O cumprimento de algum contrato de interface é tão bom em programação funcional quanto em orientação a objetos. Se uma função de classificação usar um comparador, você esperaria que o '0 seja igual, menor que o resultado negativo, maior que o comportamento positivo'.

ISP - A maioria das linguagens funcionais ainda possui estruturas. A especificação do menor conjunto de dados exigido por uma função ainda é uma boa prática. Exigir a interface menos específica para os dados (por que usar Listas de entradas quando as Enumerações de T funcionam tão bem?) Ainda é uma boa prática.

DIP - especificar parâmetros para uma função (ou uma função de ordem superior para recuperá-los) em vez de codificar a função para obter algum valor é tão bom na programação funcional quanto na orientação a objetos.

E mesmo ao fazer programação orientada a objetos, muitos desses princípios também se aplicam ao design de métodos nos objetos.

— Telastyn
fonte