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