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

36

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

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

design-patterns functional-programming solid mikera
источник
12
FWIW, это было кратко обсуждено на SO год назад
StuartLC
DI и HOF: programmers.stackexchange.com/questions/103508/…
Пол
Это видео, а также эти слайды представляют принципы SOLID, применяемые к функциональному программированию. Они оба используют язык Clojure в качестве примера, но принципы сохраняются на других языках.
масклип
slideshare.net/RichardWarburton/…
Рэй Тайек
см. также: Является ли функциональное программирование надмножеством объектно-ориентированного?
комнат

Ответы:

14

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

  • S (SRP) в FP функция создает ВСЕГДА одинаковые выходные данные для тех же аргументов, это называется ссылочной прозрачностью
  • O (OCP) в FP есть понятие, называемое алгебраическими типами данных, посмотрите, как оно относится к иерархиям классов и какую проблему пытаются решить 1
  • L (LSP) Лисковский принцип замещения - контравариантность 2
  • D (DIP) в общем функциональном программировании достигает абстракции через композицию функций, есть и другой механизм с помощью теории категорий (например, моноид или функтор), для «внедрения зависимостей» 3
AndreasScheinert
источник
21
Я все еще думаю о том, как вы перешли от принципа единой ответственности к ссылочной прозрачности . Эти двое не связаны. SRP - это функция, имеющая одну цель. В связи с этим он может быть или не быть ссылочно прозрачным.
Горан Йович
3
Ах, мой плохой - я понял это сейчас. Это эквиваленты в том смысле, что они являются принципами и образуют одну и ту же аббревиатуру, а не в смысле значения одной и той же или подобной вещи. Извините за понижение голосов!
Горан Йович
1
Правильно, это намеченный способ прочитать это. Я попытался описать сопоставление для этих терминов в контексте fp.
AndreasScheinert
Человек, я ненавижу, что вы не можете редактировать комментарий, на самом деле вещи ДОЛЖНЫ означать, по крайней мере, что-то похожее.
AndreasScheinert
Возможно, функции более высокого порядка могут обеспечить своего рода внедрение зависимости: вы вводите конкретную функцию в качестве параметра в общую функцию (более высокого порядка).
Джорджио
45

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

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

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

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

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

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

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

Telastyn
источник