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

Я вважав принципи SOLID досить корисними, коли думав про об'єктно-орієнтований дизайн.

Чи існує подібний / еквівалентний набір мовно-агностичних принципів, розроблених для функціонального програмування?

design-patterns functional-programming solid

FWIW, це було коротко обговорено в SO рік тому

— StuartLC

DI і HOF: programmers.stackexchange.com/questions/103508 / ...

— Поль

У цьому відео та цих слайдах представлені принципи SOLID, застосовані до функціонального програмування. Вони обидва використовують мову Clojure як приклад, але принципи дотримуються в інших мовах.

— mascip

slideshare.net/RichardWarburton/…

— Ray Tayek

див. також: Чи функціональне програмування є набором об'єктно-орієнтованих?

— гнат

Відповіді:

Трохи важко знайти еквіваленти, але я можу спробувати:

S (SRP) у функції FP створює ЗАВЖДИ той самий вихід для тих же аргументів, що називається референційною прозорістю
O (OCP) у FP існує концепція, яка називається алгебраїчними типами даних, подивіться, як вона стосується ієрархій класів та яку проблему намагаються вирішити ¹
Принцип заміщення L (LSP) Ліскова - це протиріччя ²
D (DIP) в загальному функціональному програмуванні досягає абстрагування за допомогою функції функцій, існують також інші механізми за допомогою теорії категорій (наприклад, моноїд або функтор) для "Введення залежностей" ³

— AndreasScheinert
джерело

Я все ще замислююся над тим, як ви перейшли від принципу єдиної відповідальності до прозорості референції . Ці два не пов'язані між собою. SRP - це функція, що має єдину мету. Зважаючи на це, він може бути або не бути референтно прозорим.

— Горан Йович

Ах, моє погано - я зараз це розумію. Це еквіваленти в сенсі буття принципів і утворюють ту саму абревіатуру, а не в сенсі значення тієї самої чи подібної речі. Вибачте за скарга!

— Горан Йович

Правильно, це призначений спосіб його прочитати. Я спробував описати відображення для цих термінів у контексті fp.

— AndreasScheinert

Людина, я ненавиджу, що ти не можеш відредагувати коментар. Насправді, ОБОВ'ЯЗКОВО БУДЕ означати хоча б щось подібне.

— AndreasScheinert

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

— Джорджіо

SOLID виявляється гарною ідеєю і для функціональних / імперативних областей.

SRP - " Вчини лише одне" було взято з імперативного програмування в першу чергу. Добре мати невеликі цілеспрямовані функції.

OCP - Добре дозволяти вам змінювати поведінку без зміни коду. Функціональне програмування використовує функції вищого порядку більше, ніж успадкування, але принцип дотримується.

LSP - Дотримання деякого контракту на інтерфейс так само добре в функціональному програмуванні, як і в об'єктно-орієнтованому. Якщо функція сортування приймає компаратор, то можна було б очікувати, що "0 дорівнює, менше, ніж забезпечує негативні результати, більше, ніж поведінка позитивних результатів".

ISP - Більшість функціональних мов все ще має структури. Визначення найменшого набору даних, необхідних функції, все ще є хорошою практикою. Потрібна найменш специфічний інтерфейс для даних (навіщо використовувати Списки ints, коли так само добре працюють Перерахунки T)?

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

І навіть при виконанні об'єктно-орієнтованого програмування багато з цих принципів застосовуються і до проектування методів в об'єктах.

— Теластин
джерело