什么是OO矩阵？
Morpheus ：我已经看到一个代理在设计中仅凭一个依赖就产生了漏洞。 开发人员使用API进行了对抗，这些API的局限性无非。 然而，它们的力量和速度仍然建立在一个基于耦合的世界上。 因此，他们将永远无法编写尽可能简单或快速的代码。
Neo ：您想告诉我的是，我可以设计对象以便在应用程序中轻松重构？
Morpheus ：不，Neo。 我想告诉您，当您准备就绪时，就不必这样做了。
服用红色药丸。 继续阅读，我将向您展示OO矩阵有多深……
在我看来，当对象的接口演变为方法时，面向对象矩阵就是发生的事情。
根据我的其他文章（耦合控制）的反转，该方法有5个调用者耦合方面。
- 返回类型
- 方法名称
- 可变数量的参数
- 可变数量的例外
- 执行线程
基于这种方法的对象交互距离Alan Kay预期的消息传递愿景还很遥远（据我了解的历史）。 通常，我们已经设想了“对象定向”（Object Orientation）如下所示，并通过线链接了漂亮的圆形对象：
但是，通过方法进行交互的对象具有非常不同的形状。 方法耦合的可变性使对象看起来更像拼图碎片。 连接器不是简单的线条，而是复杂的方法，它们以不同的方式塑造对象：
将这些方法接口对象连接在一起可形成刚性拼图。 由于所有联接，该刚性竖锯难以重构。 结果是OO矩阵：
随着Java在90年代的诞生以及在同一个十年中批准了C ++标准，“ Matrix影片”的面世是在我们将自己锁定于OO Matrix中的编程的同时，“这并非没有讽刺意味”。 我们中的一些人可能会因为重构的挫败而感觉到它的存在，而另一些人则在无所作为的背景下长大。
OO矩阵存在于我们与计算机耦合的所有编程中。 如果我们考虑：
- 该方法表示在线程堆栈上推/弹出状态
- 线程堆栈代表机器执行
- 然后基于方法设计接口将我们绑定到机器
- 因此，我们使“ OO矩阵”永久存在
真的，在现实世界中，我们在哪里找到线程堆栈？ 物体定向来自化学反应。 企业通过消息传递（例如电子邮件和文档）进行操作。 甚至我对大脑的理解都基于消息传递。 换句话说，线程堆栈是基于机器的构造。 使用线程堆栈派生的方法进行对象交互将我们绑定到了OO矩阵中。
请参阅我关于一流过程和本地微服务的其他文章，以了解我们如何摆脱OO Matrix的束缚。 这些文章演示了如何使用消息在对象之间进行接口（即，单参数未命名方法）。 这使我们摆脱了方法，线程堆栈的束缚，随后又从机器OO矩阵中释放了代码。
好吧，这就是我要描述的方式–否则，这是一个非常干燥的话题！
但是由于方法耦合问题，我肯定会在生命中所有那些小时（甚至不是几天/几周）的重构代码中哭泣。 尤其是，仿佛我们遵循了艾伦·凯（Alan Kay）专注于消息传递的愿景一样，这应该从来都不是问题。 对我来说，这实际上可能是比null更昂贵的错误。