FP and OOP are compatible (and should be)
Both OOP and functional computation can be completely compatible (and should be!). There is no reason to munge state in objects, and there is no reason to invent "monads" in FP. We just have to realize that "computers are simulators" and figure out what to simulate.
- FP and OO are completely orthogonal (based on their reductive definitions)
- OO
- The technique of using dynamic polymorphism to call functions without the source code of the caller depending upon the source code of the callee.
- FP
- Referential Transparency – no reassignment of values.
- Orthogonality does not imply mutual exclusion (just ask James Clerk Maxwell)
- It's desirable to build a system that employs both dynamic polymorphism and referential transparency.
- Dynamic polymorphism
- strongly decoupled
- Referential transparency
- predictable
- A system that is built on both OO and FP principles will maximize flexibility, maintainability, testability, simplicity, and robustness.
-- from FP vs. OO - Clean Coder Blog
I've started trying to write more functional objects after learned about Imperative Shell around the Functional Core1. And I can really feel the benefits of predictable code brought by the functional paradigm to my Ruby (Object-Oriented) code.
And I'm also switching to Elixir as my main language these days. One of the reasons behind this decision is that I think Elixir is a language that can provide both benefits of OOP and FP.
- Elixir is a functional programming language in its heart.
- But it can still achieve polymorphism by writing Protocols or using Pattern Matching.