So, if you've read all the articles above, you'll end up with the following list of requirements for a programming paradigm:
- We want a paradigm that helps us write maximally flexible code that we can develop rather than refactor when new features arrive.
- We want to be able to work conveniently with mutable structures, but sometimes use immutability.
- We don't want to create excessive atomicity (isolation) of code or abstractions.
- We want context-dependent code to be where its context is and not pollute the codebase of other contexts.
- We want to build applications based on processes while keeping business logic models as close as possible to the source data.
Why these paradigms don't suit us:
- OOP – because it has excessive atomicity that kills code flexibility, because it requires a lot of additional knowledge like SOLID, DRY, and similar concepts to work "normally," because it's based on pillars that eventually became bad practices for itself, because we're constantly leaning towards the Anemic Model anyway, which means we're moving into Procedural programming.
- Functional Programming (FP) – because although it solves OOP problems, we don't get the main feature (parallelization of calculations) of FP languages, but we do get a bunch of problems with supporting Monads, Semigroups, Setoids, immutability, and so on.
- Procedural Programming (PP) – because although it solves the problems of OOP and FP, it's outdated, because it lacks techniques and methods, because writing according to its rules is dangerous and difficult.
And that's why Function Oriented Programming (FOP) emerged, which is based on PP but includes all the best practices that emerged from FP, and doesn't include what won't give us any advantages in multi-paradigm languages:
- Separation of Behavior and Data solves the issue of excessive atomicity in OOP code and provides maximum program flexibility.
- Composition and Interface polymorphism are at the core of FOP and are considered best practices even in OOP.
- The program is built from chains/compositions of functions, each of which is fully responsible for its context and uses data in the form we deem necessary (whether it's pure data structures from the database or their aggregations/projections for more convenient work).
- In FOP, it's absolutely normal to work with mutable structures, but we can also calmly use immutability and pure functions.
- We will maximize the utilization of higher-order functions, currying, partial application, state scope, and other techniques that came from FP.
You'll learn how to use all of this in the following sections, and you can start with 🧧 Philosophy of FOP
👈 Previous chapter
Next chapter 👉