调用者或被调用者应该访问 object 字段吗？ （爪哇）

Question

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

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

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

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

Answer 1

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

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

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

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

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