I've found the SOLID principles quite useful when thinking about object-oriented design.
Is there a similar / equivalent set of language-agnostic principles tailored for functional programming?
5
-
12FWIW, this was discussed briefly on SO a year ago– StuartLCSep 19, 2012 at 7:49
-
DI and HOF: programmers.stackexchange.com/questions/103508/…– paulOct 26, 2012 at 18:30
-
This video as well as these slides present the SOLID principles applied to Functional Programming. They both use the Clojure language as an example, but the principles hold in other languages.– mascipJul 14, 2014 at 8:26
-
slideshare.net/RichardWarburton/…– Ray TayekFeb 14, 2015 at 11:24
-
see also: Is functional programming a superset of object oriented?– gnatAug 25, 2016 at 12:52
Add a comment
|
2 Answers
It is a bit difficult to find equivalents but I can try:
- S (SRP) in FP a function creates ALWAYS the same output for the same arguments this is called referential transparency
- O (OCP) in FP there is a concept called algebraic data types, have a look how it relates to Class hierarchies and what problem both try to solve 1
- L (LSP) Liskov Substitution Principle is Contravariance 2
- D (DIP) in general functional programming achieves abstraction through function composition, there are also other mechanism with the help of category theory(for example monoid or functor), for "Dependency Injection" 3
-
25I'm still thinking about how did you get from Single Responsibility Principle to referential transparency. Those two are unrelated. SRP is about a function having a single purpose. It may or may not be referentially transparent, with regard to that. Oct 26, 2012 at 19:35
-
4Ah, my bad - I get it now. These are equivalents in the sense of being principles and forming the same acronym, not in the sense of meaning the same or similar thing. Sorry for the downvote! Oct 27, 2012 at 23:15
-
1Right that's the intended way to read it. I tried to describe a mapping for those terms in context of fp. Oct 28, 2012 at 18:46
-
Man I hate that you can't edit a comment, in fact the things SHOULD mean at least something similar. Oct 31, 2012 at 20:05
-
Maybe higher-order functions can provide some kind of dependency injection: you inject a concrete function as a parameter into a generic (higher-order) function.– GiorgioDec 7, 2012 at 12:22
SOLID turns out to be a good idea for the functional/imperative realms too.
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.
answered Oct 26, 2012 at 18:43
