Morpheus: I’ve seen an agent punch holes in designs with only a single dependency. Developers have fought against them with APIs that resulted in nothing but limitations. Yet their strength and their speed are still based in a world that is built on coupling. Because of that, they will never be able to write as simple or as fast code as you can.
Neo: What are you trying to tell me, that I can design objects for easy refactoring within applications?
Morpheus: No, Neo. I’m trying to tell you that when you’re ready, you won’t have to.
Take the red pill. Read on and I show you how deep The OO Matrix goes…
In my opinion, The OO Matrix is what happened to Object Orientation when the interfacing of objects devolved to the method.
As per my other article Inversion of (Coupling) Control, there are 5 caller coupling aspects to the method.
- Return type
- Method name
- Variable number of parameters
- Variable number of exceptions
- Executing thread
This method based object interaction is a long way away from the intended message passing vision by Alan Kay (as I understand the history). Typically, we have envisioned Object Orientation to look as follows, with nice round objects linked by lines:
However, objects interacting via methods have very different shapes. The variability of the method coupling has objects look a lot more like jigsaw pieces. The connectors are not simple lines, but complex methods that shape the object differently:
Piecing these method interfacing objects together forms a rigid jigsaw. This rigid jigsaw is difficult to refactor due to all the coupling. The result is The OO Matrix:
With the birth of Java in the 90’s and the ratification of the C++ standard in the same decade, “it is not without a sense of irony” that the Matrix film came out about the same time we locked ourselves into programming within The OO Matrix. Some of us may sense it’s existence with refactoring frustrations, while others grew up in it knowing no difference.
The OO Matrix exists all around our programming coupling us to the machine. If we consider:
- the method represents pushing/popping state on/off the thread stack
- the thread stack represents execution by machines
- then designing interfaces based in methods is binding us to the machines
- and as such we perpetuate The OO Matrix
And really, where in the real world do we find a thread stack? Object Orientation was derived from chemical reactions. Businesses operate in message passing (e.g. emails and documents). Even my understanding of our brains is built on message passing. In other words, thread stacks are a machine based construct. Using the thread stack derived method for object interaction binds us into the machine – The OO Matrix.
See my other articles on First-Class Procedures and Local Microservices about how we can break free from The OO Matrix. These articles demonstrate using messages to interface between objects (i.e. single parameter unnamed methods). This breaks us free from the method, the thread stack, and subsequently freeing our code from machines – The OO Matrix.
Well, this is how I like to describe it – as it’s a pretty dry topic otherwise!
But I certainly cry about all those hours (if not days/weeks) of refactoring code in my life due to the method coupling problem. Especially, as if we followed Alan Kay’s vision of focusing on message passing, this should never have been a problem. And to me, this may actually be a more expensive mistake than null.
Published on Java Code Geeks with permission by Daniel Sagenschneider, partner at our JCG program. See the original article here: What is The OO Matrix? Opinions expressed by Java Code Geeks contributors are their own. |
