What is The OO Matrix?

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.

1. Return type
2. Method name
3. Variable number of parameters
4. Variable number of exceptions
5. 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.

DDD Perth 2019 Preview

This article is a little taster to wet your appetite regarding my talk at DDD Perth 2019.  Given there are 6 tracks competing for your attention, I'm just here to say that if you have a technical inclination don't miss:

Dependency Injection is only 1/5 of the Inversion of Control problem

First of all, the presentation is full of Matrix references.  You get to geek out on not only the latest in tech patterns, but do it with lots of Sci-Fi references.  Plus the Matrix is a great analogy for my talk, as I show you what is the OO Matrix.

Yes, the OO Matrix is very real if you write any mainstream OO languages (and even functional languages).  You are all plugged into it!   Some of you, like Neo, may sense it's existence.   Others of you grew up in it, knowing no difference!  History even has some sense of irony that the Matrix film came out around the time the OO Matrix plugged us all in.   I will show you what it is and there is no going back, once you see it.  Get ready to swallow the "red pill" and join me in Zion.

And if that alone does not entice you enough, then get the "geek credit" for being present at the first talk where I introduce:

• Continuation Injection
• Thread Injection

If you think Dependency Injection shaped much of mainstream development, then you'll be able to tell your co-workers, new interns, even your kids that you were present when Continuation Injection and Thread Injection were first announced at a conference!

You may think Inversion of Control and Dependency Injection are dry topics.   I assure you will be far from bored, and I'll leave you like you did walking out of the Matrix. In the words of Keanu Reeves....   "WHOA"!