Эквивалент принципов SOLID для функционального программирования

Я нашел принципы SOLID весьма полезными, когда размышляю над объектно-ориентированным дизайном.

Существует ли подобный / эквивалентный набор не зависящих от языка принципов, адаптированных для функционального программирования?

design-patterns functional-programming solid

— mikera
источник

FWIW, это было кратко обсуждено на SO год назад

— StuartLC

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

— Пол

Это видео, а также эти слайды представляют принципы SOLID, применяемые к функциональному программированию. Они оба используют язык Clojure в качестве примера, но принципы сохраняются на других языках.

— масклип

slideshare.net/RichardWarburton/…

— Рэй Тайек

см. также: Является ли функциональное программирование надмножеством объектно-ориентированного?

— комнат

Ответы:

Это немного трудно найти эквиваленты, но я могу попробовать:

S (SRP) в FP функция создает ВСЕГДА одинаковые выходные данные для тех же аргументов, это называется ссылочной прозрачностью
O (OCP) в FP есть понятие, называемое алгебраическими типами данных, посмотрите, как оно относится к иерархиям классов и какую проблему пытаются решить ¹
L (LSP) Лисковский принцип замещения - контравариантность ²
D (DIP) в общем функциональном программировании достигает абстракции через композицию функций, есть и другой механизм с помощью теории категорий (например, моноид или функтор), для «внедрения зависимостей» ³

— AndreasScheinert
источник

Я все еще думаю о том, как вы перешли от принципа единой ответственности к ссылочной прозрачности . Эти двое не связаны. SRP - это функция, имеющая одну цель. В связи с этим он может быть или не быть ссылочно прозрачным.

— Горан Йович

Ах, мой плохой - я понял это сейчас. Это эквиваленты в том смысле, что они являются принципами и образуют одну и ту же аббревиатуру, а не в смысле значения одной и той же или подобной вещи. Извините за понижение голосов!

— Горан Йович

Правильно, это намеченный способ прочитать это. Я попытался описать сопоставление для этих терминов в контексте fp.

— AndreasScheinert

Человек, я ненавижу, что вы не можете редактировать комментарий, на самом деле вещи ДОЛЖНЫ означать, по крайней мере, что-то похожее.

— AndreasScheinert

Возможно, функции более высокого порядка могут обеспечить своего рода внедрение зависимости: вы вводите конкретную функцию в качестве параметра в общую функцию (более высокого порядка).

— Джорджио

SOLID оказывается хорошей идеей и для функциональных / императивных сфер.

SRP - « Делай только одно» было взято из императивного программирования в первую очередь. Иметь маленькие, сфокусированные функции - это хорошо.

OCP - Позволять вам изменять поведение без изменения кода - это хорошо. Функциональное программирование использует функции более высокого порядка больше, чем наследование, но принцип верен.

LSP - соблюдение некоторого контракта интерфейса так же хорошо в функциональном программировании, как и в объектно-ориентированном. Если функция сортировки использует компаратор, то можно ожидать, что поведение «0 равно, меньше, чем дает отрицательные результаты, больше, чем положительные результаты».

ISP - у большинства функциональных языков все еще есть структуры. Указание наименьшего набора данных, требуемого функцией, все еще является хорошей практикой. Требование наименее специфического интерфейса к данным (зачем использовать списки целых чисел, когда перечисления T работают так же хорошо?) - все еще хорошая практика.

DIP - Задание параметров для функции (или функции более высокого порядка для их извлечения), а не жесткое кодирование функции для получения некоторого значения, столь же хорошо в функциональном программировании, как и в объектно-ориентированном.

И даже при выполнении объектно-ориентированного программирования многие из этих принципов применимы и к разработке методов в объектах.

— Telastyn
источник