本地微服务：面向对象的行为耦合问题

这是一个由三部分组成的系列文章的第一篇，该系列文章介绍了我如何看待微服务如何缓解对象定向行为耦合问题。 在研究这个问题时，它确定了“本地”微服务的能力。

该系列文章分为三部分，内容如下：

• 确定对象定向行为耦合问题
• 微服务如何减少这种耦合问题
• 本地微服务如何避免不必要的繁重开销

我所说的本地微服务是通过引用微服务传递的。 现在，我看到类似于EJB 1.0规范的微服务。 就像现在的微服务一样，EJB之间的所有调用都是远程的。 由于远程调用开销，EJB 2.0引入了会话（本地，通过引用传递）EJB。

现在我们可能会争辩说，在过去的20年中，基础设施和网络已经有了显着改善。 网络上的这种改进可能会导致对技术开销的争论不成立。 但是，将每个微服务分别托管在云中也会产生实际的美元影响。 能够在同一容器中运行本地微服务实际上可能是本地化的财务开销驱动因素。

本地微服务还有其他原因，例如远程微服务的重构工作。 另外，当它们都位于同一部署容器中时，我们将研究独立部署的问题。 但是，我们将在本系列的后续部分中介绍这些内容。 对于第一部分，我们将着眼于确定对象定向行为耦合问题。

第一部分：面向对象的行为耦合问题

从结构上讲，对象定向将对象连接在一起，形成一个非常漂亮的图形。 这些通常如下所示：

这些图表示应用程序中的对象关系。 每行是对另一个对象的字段引用。 例如，这可以对您的个人详细信息进行建模，使其具有地址，电话号码和其他各种包含信息的对象。

但是，此结构不代表应用程序的行为。 它仅指示对象之间的结构关系。 我无法调用对象引用。 我使用对象引用来访问对象上的方法。 应用程序的行为实际上遵循方法调用，而不是上面的结构图线。 换句话说，程序控制不遵循堆存储器对象引用。 程序控制遵循线程堆栈上的方法调用。

因此，我们可以使用方法调用绘制上面的图形，对吗？ 不，方法耦合要复杂得多，而不仅仅是对象引用最多随类型而变化（请参见耦合控制反转 ）。 方法有：

• 特定的返回类型
• 一个名字
• 不同类型的参数数量不同
• 不同类型的异常数量不同
• 执行它们的线程

在对象之间画一条简单的线来表示行为关系并不尊重行为耦合的复杂性。 在对象结构图中，更改一条线只是更改对另一个对象的引用（内存地址）。 是的，限制取决于所引用对象的类型，但这是将两个对象耦合为结构关系的单个地址值。 方法不是这种情况。

每个方法行为连接器都是不同的形状。 就对象结构连接器而言，对象引用的形状是对象类型和内存地址。 这在所有对象引用中都是一致的。 然而，由于上述五个方面，对于方法，连接器具有不同的形状。 换句话说，一个方法可能有1个参数，而另一个方法有3个参数并抛出2个异常。 每个方法调用连接器的形状差异很大。

绘制对象的行为图更类似于以下内容：

方法之间的每个连接器都具有不同的形状，就像拼图一样。

我们将对象拼凑在一起，以实现应用程序的行为。 这就是为什么重构应用程序如此困难的原因。 就像试图移动拼图碎片来制作新照片一样。 我们最终不得不大刀阔斧地进行改动，以使它们甚至试图适应新的画面。

我相信，这也是为什么面向对象从未提供理想的类重用的原因。 重用对象就像试图重用一个拼图的拼图碎片来完成另一个拼图。 现在，如果拼图有些相似，您可以将它们拼在一起。 但是，通常您不得不更改部件（对象）以适合其他拼图（应用程序），从而失去重用性。

因此，方法耦合问题在整体面向对象系统中产生了严重的行为耦合问题。 重构是一项昂贵的工作，因为它不会在漂亮的圆形对象之间重新绘制线条。 重构正在重塑碎片以适应新的拼图图片。

现在，我可以通过许多API开发来继续进行类比，以尝试标准化拼图碎片并查找代表大多数系统的通用图片。 但是，我希望您能与我一起看到很多对象定向行为问题不在于对象，而在于方法的使用。

是的，对于面向对象的纯粹主义者而言，面向对象更多地是关于松散耦合的消息传递。 换句话说，诸如Erlang之类的语言可能更接近于“对象定向”的意图。 但是，我的重点是对“对象定向”即对象和方法的“主流”理解。

请继续关注我的下一部分，关于微服务如何帮助缓解对象定向方法耦合问题。

翻译自: https://www.javacodegeeks.com/2019/05/local-microservices-object-orientation-behaviour-coupling-problem.html