Исходя из языка ООП, я знаком с принципами SOLID объектно-ориентированного дизайна. Похоже, что некоторые из них вписываются в модель функционального программирования, в то время как другие части не имеют смысла в мире, не имеющем состояния. Существует ли аналогичный набор принципов для рефакторинга функционального кода?
SOLID для функционального программирования
Ответ 1
Насколько я знаю (я не эксперт), принципы SOLID ничего не говорят о состоянии. Они также должны применяться в функциональных языках программирования. Они больше советуют о том, как достичь модульности.
Некоторые из них довольно очевидны или, по крайней мере, хорошо известны. Единственная ответственность - принцип UNIX "сделать одно и сделать это хорошо", что еще более популярно в функциональных языках, где "композиция" широко используется аналогично. Принцип разделения сегментов также очень естественен (у вас интерфейсы модулярны и сохраняются ортогональные понятия). Наконец, инверсия зависимостей - это просто имя "абстракция" и вездесущее в функциональном программировании.
Принципы OL, Open/Closed и LSP, более ориентированы на языки, основанные на наследовании, в качестве основной концепции разработки программного обеспечения. Значения/модули функциональных языков не имеют открытой рекурсии по умолчанию, поэтому "наследование реализации" используется только в очень конкретных случаях. Композиция является предпочтительной. Я не уверен, как вы должны интерпретировать принцип Open/Closed в этой настройке. Вы можете подумать об инкапсуляции, какие функциональные программы также используют много, используя абстрактные типы и т.д.
Наконец, принцип заимствования Лискова может казаться о наследовании. Функциональные языки не всегда используют подтипирование, но когда они это делают, действительно предполагается, что "производные типы" должны сохранять спецификацию "базовых типов". Функциональные программисты, конечно, тщательно определяют и уважают интерфейс и свойства своих программ, модулей и т.д. И могут использовать алгебраические рассуждения (это эквивалентно этому, поэтому я могу подставить...) на основе этих спецификаций при программировании, рефакторинге, и т.д. Однако, как только вы избавитесь от идеи "наследования по умолчанию", у вас гораздо меньше проблем с нарушениями интерфейса, поэтому LSP не подчеркивается как жизненно важная защита, как в ООП.
Ответ 2
Это видео содержит принципы SOLID и как их применять в Clojure.
Это показывает, как эти принципы сохраняются в функциональном мире так же, как и в ООП, потому что нам все еще нужно решать одни и те же основные проблемы. И в целом, это заставило меня подумать, что функциональное программирование лучше подходит для дизайна SOLID.