这篇文章是我周日在 dzone 上看到的，即使结合了黑客帝国，但是对我来说还是有点难懂，所以翻译得不咋地，有兴趣的同学可以看下原文。
原文自国外技术社区dzone，作者为 Daniel Sagenschneider ，传送门
墨菲斯：我曾经看到一个特工在设计上只使用一个独立的依赖来处理。因此，开发者们开始使用 API 来与他们展开斗争从而形成限制。但是，正因为他们的力量和速度都仍然基于耦合的世界中，因此他们无法编写出简单有效的代码。
尼奥：你想说什么？是想说我可以设计出一种方法能够方便地进行程序重构吗？
墨菲斯：不对，尼奥。我只是想告诉你当你准备好了，就不需要这样做了。吞掉这红色药丸。往下读我会告诉你这 OO matrix 的洞到底有多深...
在我的理解中，OO matrix 是指当对象接口转移到方法的时候，面向对象会发生什么事情。
在我前一篇文章 Inversion of (Coupling) Control 中有说过，在方法中有五个调用者耦合切面：
- 返回类型
- 方法名称
- 参数变量个数
- 异常的变量个数
- 执行线程
这种基于对象交互的方法与 Alan Kay 所提出的预期消息传输的想法（据我所了解的）还是相差不少的。通常，我们设想的面向对象应该是如下所示，每个圆由线连接起来：
然而，通过方法产生交互的对象具有非常不同的表现形式。方法耦合的可变性使得对象看起来更像拼图碎片。它们之间的连接不是简单的线，而是那些塑造对象差异的复杂方法：
将这些方法对象拼接在一起形成一个拼图。由于它们都耦合在一起了，所以这个拼图很难被重构。这个结果就是 OO matrix：
早在 Java 诞生的90年代，以及同时间下发下来的 c++ 标准，当我们将自己锁进了 OO matrix 的时候，"不讽刺地说"，黑客帝国电影也是在那个时候出现的。一些人通过在重构的折磨中来认识到它的存在，而另外的一些人则还被蒙在鼓里。
OO matrix 存在于我们的日常编程中，当我们在想：
- 方法在 打开/关闭 线程栈时表示为 push/pop 状态
- 线程栈由机器表示执行
- 然后设计基于方法的接口将我们和机器绑定在一起
- 因此，OO matrix 就永存了！
说真的，在现实世界中，我们能找到一个线程栈吗？对象交互诞生于化学反应（Object Orientation was derived from chemical reactions.）。企业通过消息传递来运营（例如邮件和文档）。甚至我们大脑中的认知也是建立于信息传递。换句话说，线程栈是一个基于机器的构造。使用线程栈派生的方法进行对象交互来链接人类与计算机 — OO matrix。
嗯，这就是我描绘它的方法 — 否则这话题也太无聊枯燥了。
但是，由于方法耦合问题，我也试过为代码重构难受了数个小时。也许特别是，如果我们遵循了 Alan Kay 的信息传递理念，这应该就不是一个问题了。但对我来说，这实际上也是一份珍贵的错误经验。