The central tenet of object-oriented programming is perhaps the encapsulation of shared mutable state and behavior into a single unit, the object. This is beneficial because shared mutable state is mutable and shared, and by limiting what behaviors can mutate the state and how the state is shared, we make the program comprehensible.
Everybody can come up with a scheme to mutate state and share it, in a way that they themselves think they are able to understand all the implications of doing so but almost often they are wrong. There are hidden implications of having excessive mutable state listed below.
A real programmer should face mutable shared state with humility and not multiply it reveling in his own ability to understand it.
Object-oriented programming does not limit the programmer from increasing mutability and “sharedness” of state. It merely suggests good practices called “design patterns” that programmers follow them, when convenient, if at all.
As a consequence we have:
- Good practices decided by purported experts like Gang of Four and people like Martin Fowler who do not have any good reason why they are right except that they are influential. They got influential by preaching feel good practices they discovered through experience which like religion feels right. And to be fair there is some truth in good design practices much like how basic religious tenets of mainstream religions are honorable. But excessive adherence to such practices often reveals their weaknesses.
- The entire industry plagued with hipsters who come up with one framework/paradigm every week that follow the above mentioned good practices in various ways trying to find the next great magic formula for managing complexity.
- Abstractions that are only used in job interviews to hire programmers to maintain poorly written code which does not use any of the said abstractions.
- Debuggers are necessary because of excessive mutable state.
- We have to constantly run the program to know if it works. Test-driven development, behavior drive development arises from this. This is called operational semantics as opposed to denotational semantics.
- Formal verification methods involving mutable state is exceedingly complex.
Pure functional programming school of thought plans to create a brave new world order by liberating people from this mess. You have nothing to lose but your chains. 😉
- Pure functional programming abolishes all mutable state. Mutability only exists as a syntactic sugar if at all, and only a simulacrum of mutation exists.
- Pure functional programming abolishes all shared state.
- As a consequence encapsulation is unnecessary and even detrimental. All we need is namespacing.
- Pure functional programming does side effects without losing denotational semantic properties of functions.
- Instead of relying on experts preaching good practices we rely on theoretical results which yield terseness and better denotational semantics i.e. the ability understand program behavior without running it.
- Debuggers are rarely needed.
- Test-driven development is replaced with proof-driven development and random test case generation.
- Job interviews are about abstractions which are actually used in the code base not some nice to have design pattern postponed because of deadlines to gradually create messy code.