The document discusses applying SOLID principles to functional programming (FP). It argues that SOLID is often interpreted as being about object-oriented programming (OOP), but its goals of encapsulation, separation of concerns, and low coupling can also be achieved in FP. Extreme application of SOLID in OOP can result in many small, single-method classes and interfaces along with pervasive use of decorators, but FP approaches this through functions, function composition, and type signatures, leading to simpler code. An example message store implementation in F# demonstrates how SOLID is realized through types and pure functions in a functional style.

1. Functional SOLID
(Can I apply SOLID to FP?)
Alexandr Sugak,
Software Architect at Sigma Software,
https://github.com/AlexSugak

2. SOLID is about OOP
OR IS IT?

3. SOLID example
https://www.pluralsight.com/courses/encapsulation-solid
• Implement a message store;
• Messages are stored as files on disk;
• Messages are cached;
• Access to messages is logged.

4. SRP: one reason to change
• A module/class must encapsulate one thing;
• How to find this one thing?
• RCM’s answer: object must have one reason
for change.

5. SRP: file store

6. OCP: closed for modification
• Could it be that behavior of a class/module
may be extended/changed in future?
• How can we extract this reason for change as
an abstraction?
• How can we program that class/module once
and for all (close it)?

7. OCP: opened for extensibility
It is agreed that usually it is better to achieve
extensibility and reuse by composition instead of
inheritance.
https://en.wikipedia.org/wiki/Composition_over_inheritance
GoF:
“Ideally you shouldn’t have to create new components to achieve reuse. You should be
able to get all the functionality you need just by assembling existing components through
object composition. But this is rarely the case, because the set of available components is
never quite rich enough in practice. Reuse by inheritance makes it easier to make new
components that can be composed with old ones. Inheritance and object composition thus
work together.
Nevertheless, our experience is that designers overuse inheritance as a reuse technique
and designs are often made more reusable (and simpler) by depending more on object
composition. You’ll see object composition applied again and again in the design patterns.”

8. OCP: cache store via decorator

9. LSP: conforming to semantics of
an abstraction
What can we assume about implementation of
abstraction?
• Command Query Separation;
• Strong typing enforces semantics;
• Maybe<T> instead of nulls;
• Strongly typed errors;
• Code Contracts;
• Checked exceptions in Java;
• Etc.

10. LSP: store logger

11. ISP: do not depend on things you
do not use
• The smallest interface has one method;
• You cannot violate ISP if all interfaces have
one method.

12. ISP: message store

13. DIP: high must not depend on low
• Both must depend on abstraction;
• Programming against interfaces.

14. DIP: message store

15. SOLID Message Store:
decorators everywhere!
https://www.pluralsight.com/courses/encapsulation-solid

16. Extreme SOLID results in
• A bunch of one-method interfaces;

17. Extreme SOLID results in
• A bunch of one-method interfaces;
• A lot of small one/two-method classes;

18. Extreme SOLID results in
• A bunch of one-method interfaces;
• A lot of small one/two-method classes;
• Decorators everywhere;

19. Extreme SOLID results in
• A bunch of one-method interfaces;
• A lot of small one/two-method classes;
• Decorators everywhere;
• Compositions of complex behaviors out of
simple classes;

20. Extreme SOLID results in
• A bunch of one-method interfaces;
• A lot of small one/two-method classes;
• Decorators everywhere;
• Compositions of complex behaviors out of
simple classes;
• Other developers don’t like to work with such
code base.

21. Extreme SOLID results in

22. Extreme SOLID results in

23. Extreme SOLID results in doing
this:
https://github.com/AlexSugak/concurrencysample

24. To implement this:
https://github.com/AlexSugak/concurrencysample

25. Doing SOLID in OO requires
experience and discipline:
• Such code is not idiomatic to C# or Java;
• Our tools (IDE) are not optimized for this;
• Majority of developers are not used to this;
• Requires deep knowledge and understanding
in majority of the team.

26. SOLID in FP
OOP FP
One-method interfaces
One-method classes
Decorators
Composition

27. SOLID in FP
OOP FP
One-method interfaces Functions
One-method classes Functions
Decorators Functions
Composition Function composition

28. Message Store in F#, types:
https://github.com/AlexSugak/message-store

29. Message Store in F#, types:

30. Message Store in F#, types:

31. Partial Application of functions:

32. Partial Application of functions:

33. Pipe operator in F#:

34. Message Store in F#, file store:

35. Message Store in F#, store
cache:

36. Message Store in F#, store
logger:

37. Message Store in F#,
composition:

38. Message Store in F#,
composition:

39. Message Store in F#,
composition:

40. Message Store in F#, simpler:
http://www.fssnip.net/h4

41. SOLID in FP, simpler, easier:
• Coming up with a good abstraction is hard;
• PL should help with that, not make it more
difficult;
• FP focuses on types, function signatures,
composition, making it easier to reason about
abstractions;
• The result artifact is usually simpler.

42. Thank you!
Questions?

43. F# in Kharkiv:
https://www.facebook.com/groups/kharkivfsharp/