Java 调用者或被调用者是否应该访问对象字段？（爪哇）

我有一个SpringWeb服务。在构建

响应

时，我们的

ResponseBuilder

类使用

上下文

对象。

Response

上的每个字段都有自己的关联业务逻辑和

[Name]FieldBuilder

Singleton

类，该类对存储在

上下文中的某些信息进行操作。我们希望避免
RequestScope
并在这些类中存储状态，以防止Java实例化过多的对象（目前我们正在使用>500tps）

上下文
对象具有
媒体
、
活动
、
客户端信息
等。每个内部对象中都有其他字段。每个
响应
字段只需要存储在
上下文中的部分信息

从设计角度来看，我是否应该按原样将
上下文
传递给每个
字段生成器
，并让他们将其解包？还是应该在
ResponseBuilder
中进行解包，并且
FieldBuilder
的方法签名应该更加具体

如果需要更多的上下文，请告诉我，谢谢。
我认为需要更少的上下文（双关语）。您所描述的
上下文
将显示a的许多问题，即使它是一个没有任何逻辑的纯数据结构。当在一个对象中放入如此多的数据时，随着应用程序的增长，对象所能做的唯一事情就是随着应用程序的增长而增长

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

如前所述，您可以通过传递
上下文的片段而不是完整的对象来减轻这种影响。这是个好主意，我建议你这样做；但可能不会。归根结底，
上下文
拥有如此多的数据这一事实将推动整个应用程序的设计，不管所有对象是否直接知道
上下文

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

您可能会在函数式编程研究中找到灵感。
谢谢您富有洞察力的评论。我们现在确实在以程序的方式做事，正如你所说的，这不一定是坏的。但我想我们可以试着让事情面向对象，或者我们可以走FP路线，在我们反应的过程性上加倍努力。您所说的“将数据与逻辑分离”的应用程序到底是什么意思？此外，将
上下文
对象分解为单个对象是另一种途径吗？我觉得它实际上与传递
Context
片段的区别是一样的。。。因此，即使没有“上帝对象”，问题仍然存在。将
上下文
划分为单独的数据结构不会减少程序性，只要它与业务逻辑保持分离；但我认为每一种范式都倾向于小而连贯的片段，而不是相反的片段。