函数式编程SOLID用于函数式编程
来自OOP语言，我熟悉面向对象设计的SOLID原则。看起来这些中的一些可能适合功能性编程模型，而其他部分在缺乏状态的世界中没有意义。是否有一套类似的重构功能代码的原则？函数式编程SOLID用于函数式编程
据我所知（我不是专家），固体原则并没有说明任何关于状态的内容。它们也应该适用于函数式编程语言。他们对如何实现模块化提出了更多建议。
其中有些是相当明显或至少是众所周知的。单一职责是UNIX原则“做一件事并做得很好”，在“组合”被广泛使用的功能语言中，这一原则更为流行。接口隔离原理也非常自然（让你的接口模块化并保持正交概念分离）。最后，依赖倒置只是“抽象”的名称，在函数式编程中是无处不在的。
作为核心软件工程概念，“OL”原则Open/Closed和LSP更多地面向基于继承的语言。功能性语言值/模块默认没有开放递归，所以“实现继承”仅用于特定情况。组合物是优选的。我不确定你应该如何解释该设置中的开放/封闭原则。你可能会认为它是关于封装的，哪些功能程序也使用很多，使用抽象类型等。
最后，Liskov替代原则似乎是关于继承。函数式语言并不总是使用子类型，但是当它们这样做时，确实假定“派生类型”应该保留“基本类型”的规范。函数式程序员当然要小心地指定和尊重他们的程序，模块等的接口和属性，并且可以在编程，重构等基础上根据这些规范使用代数推理（这相当于这个，所以我可以替代...）等等。然而，一旦你摆脱了“默认继承”的想法，你的接口违规问题就会少得多，所以LSP不像它在OOP中那样被强调为重要的保障。
此评论不仅有助于查看OO和FP之间的链接，还有助于更直观地理解SOLID原则。谢谢。 – lionel 2015-12-02 01:12:13
OCP不受继承限制，这是一种常见的误解，可能是因为它经常用策略模式或模板方法模式来解释。但是黑盒模块可以重复使用，并且可以在不改变其内部的情况下进行扩展，只需将参数传递给它们（可能是功能性的）就完全与继承无关。即使是“战略模式”，使用仿函数而不是战略对象层次结构实现起来也更简单。 – 2016-06-18 08:24:22
This video介绍了SOLID原则，以及如何在Clojure中应用它们。
它展示了这些原则在OOP中如何保持在功能世界中，因为我们仍然需要解决相同的基础问题。总的来说，这让我觉得功能编程更适合SOLID设计。
实际上，实质上采用了极端**的SOLID是**在面向对象语言中具有不可变状态的函数式编程。 – TeaDrivenDev 2014-02-18 21:22:20