调用者或被调用者应该访问对象字段吗？（爪哇）答案

【问题标题】：Should the caller or callee access object fields? (Java)调用者或被调用者应该访问对象字段吗？（爪哇）
【发布时间】：2021-05-19 00:39:46
【问题描述】：

我有一个 Spring Web 服务。在构建Response 时，我们的ResponseBuilder 类使用Context 对象。 Response 上的每个字段都有自己关联的业务逻辑和[Name]FieldBuilder Singleton 类，它对存储在Context 中的一些信息进行操作。我们希望避免RequestScope 并将状态存储在这些类中，以防止 Java 实例化过多的对象（我们目前使用 >500tps）。

Context 对象具有Media、Campaigns、ClientInfo 等。在这些内部对象中的每一个内部都有更多字段。每个Response字段只需要Context中存储的部分信息。

从设计的角度来看，我应该将Context 原样传递给每个FieldBuilder，然后让他们解压吗？还是应该在ResponseBuilder中解包，FieldBuilder的方法签名更具体？

如果需要更多上下文，请告诉我，谢谢。

【问题讨论】：

标签： java spring oop design-patterns

【解决方案1】：

我认为需要更少的上下文（双关语）。您所描述的Context 将表现出god object 的许多问题，即使它是一个没有任何逻辑的纯数据结构。当这么多数据被放入一个对象时，随着应用程序的增长，该对象唯一能做的就是与它一起增长。

最终每个确实有业务逻辑的方法都需要Context 作为参数。这将导致逻辑被实现为函数或过程，因为没有数据可以与之组合来创建对象（所有数据都归Context所有）。

您可以尝试通过传递Context 的片段而不是完整的对象来减轻这种影响。这是个好主意，我建议这样做；但它可能不会是the difference between OOP and procedural programming。最终，Context 拥有这么多数据这一事实将推动整个应用程序的设计，无论所有对象是否都直接知道Context。

调用者与被调用者访问参数字段的问题假定了一个非面向对象的范例。在 OO 中，对象更喜欢对它们拥有的数据进行操作。因此，也许我能提供的最好建议是放弃 OOP 是“好”而 OOP 的任何替代方案都是“坏”的想法。这里的描述给人一种强烈的印象，即这个应用程序不是面向对象的。这既不好也不坏，但是将 OO 设计模式混合到将数据与逻辑分离的应用程序中可能不会产生预期的结果。

您可能会在研究函数式编程时找到灵感。

【讨论】：

感谢您富有洞察力的评论。我们现在确实在以程序化的方式做事，正如你所说，这不一定是~坏的~。但我想我们可以尝试让事情面向对象，或者我们可以走 FP 路线并加倍关注我们响应的程序性质。但是，“将数据与逻辑分离”的应用程序到底是什么意思？
另外，将Context 对象分解为单独的对象是另一条路径吗？我觉得这实际上与传递Context 的片段相同......所以即使没有“上帝对象”，问题仍然存在。
将Context 划分为单独的数据结构不会使其程序化程度降低，只要它与业务逻辑分开即可；但我认为每个范式都更喜欢小的有凝聚力的部分，而不是相反。