SOLID for functional programming

This video presents the SOLID principles, and how to apply them in Clojure.

It shows how these principles hold in the Functional world as much as in OOP, because we still need to solve the same underlying problems. And overall, it made me think Functional Programming is better suited for SOLID design.

Actually, SOLID Could be a good idea to have a better principle for Functional Programming:

• SRP: Only do one thing was taken from imperative programming in the first place. Having small, focused functions is good.

• OCP: Allowing you to change behaviors without modifying code is good. Functional Programming uses higher-order functions more than inheritance, but the principle holds.

• LSP: Abiding by some interface contract is just as good in functional programming as in object-oriented. If a sort function takes a comparator, then you would expect the '0 is equals, less than provides negative results, greater than positive results' behavior.

• ISP: Most functional languages still have structs. Specifying the smallest set of data required by a function is still good practice. Requiring the least specific interface to the data (why use Lists of ints when Enumerations of T work just as well?) is still good practice.

• DIP: Specifying parameters to a function (or a higher-order function to retrieve them) rather than hard coding the function to go get some value is just as good in functional programming as in object-oriented.

And even when doing object-oriented programming, many of these principles apply to the design of methods in the objects too.

"Richard Warburton, a member of the London JCP Committee, in his presentation describes the SOLID principles as one example of well-established object oriented programming design principles, identified by Robert C. Martin in the early 2000s, and looks at each of the five principles trying to find a functional equivalent or at least something related on the function side. Richards experience is that although many developers don’t know how to use their existing design skills in functional design, functional programming can often help in implementing the SOLID principles and also that a functional mindset can actually help in achieving one important aspect of object-orientation, encapsulation."

Further information:

• Object Oriented Design Principles and Functional Programming - https://www.infoq.com/news/2014/03/oo-functional-programming/

• Equivalent of SOLID principles for functional programming - https://softwareengineering.stackexchange.com/questions/165356/equivalent-of-solid-principles-for-functional-programming

As far as I know (I'm no expert), SOLID principles do not tell anything about state. They should be applicable as well in a functional programming languages. They're more advice about how to achieve modularity.

Some of them are rather obvious or at least well-known. Single-responsibility is the UNIX principle "do one thing and do it well", which is even more popular in functional languages where "composition" is widely used, similarly. The Interface Segregation Principle is very natural as well (have your interfaces modular and keep orthogonal concepts separated). Finally, Dependency Inversion is just a name for "abstraction" and is omnipresent in functional programming.

The "OL" principles, Open/Closed and LSP, are more oriented towards languages based upon inheritance as a core software engineering concept. Functional languages values/modules do not have open recursion by default, so "implementation inheritance" is only used in very specific cases. Composition is preferred. I'm not sure how you should interpret the Open/Closed principle in that setting. You may consider it is about encapsulation, which functional programs also use a lot, using abstract types and such.

Finally, the Liskov Substitution Principle may seem to be about inheritance. Functional languages do not always use subtyping, but when they do it is indeed assumed that "derived types" should preserve the specification of "base types". Functional programmers are of course careful to specify and respect the interface and properties of their programs, modules etc., and may use algebraic reasoning (this is equivalent to this so I can substitute...) based on those specifications when programming, refactoring, etc. However, once you get rid of the "inheritance by default" idea, you have much less problems of interface violations, so LSP is not emphasized as a vital safeguard as it is in OOP.