调用者或被调用者应该访问对象字段吗( java 语)

guicsvcw  于 2021-07-23  发布在  Java
关注(0)|答案(1)|浏览(266)

我有一个springweb服务。在构建 Response ,我们的 ResponseBuilder 类使用 Context 对象。每一个领域 Response 有自己的关联业务逻辑和
[Name]FieldBuilder Singleton 类,它对存储在 Context . 我们想避免 RequestScope 并将状态存储在这些类中,以防止java示例化过多的对象(目前我们使用的是>500tps)。
这个 Context 对象具有 Media , Campaigns , ClientInfo ,等等。每个内部对象中都有进一步的字段。每个 Response 字段只需要存储在 Context .
从设计的Angular 来看,我应该通过吗 Context 对每一个 FieldBuilder ,然后让他们打开 Package ?或者开箱是在 ResponseBuilder 以及 FieldBuilder 具体点?
请让我知道如果需要更多的上下文,谢谢。

wlp8pajw

wlp8pajw1#

我认为需要较少的上下文(双关语)。这个 Context 您所描述的将展示上帝对象的许多问题,即使它是没有任何逻辑的纯数据结构。当这么多数据放在一个对象中时,随着应用程序的增长,对象唯一能做的就是随着它一起增长。
最终,每个具有业务逻辑的方法都需要 Context 作为论据。这将导致逻辑被实现为函数或过程,因为没有数据可以与之结合来创建对象(所有数据都属于 Context ).
正如您所描述的,您可以通过传递 Context 而不是完整的对象。这是个好主意,我建议你这样做;但这可能不是面向对象编程和过程编程之间的区别。最终,事实是 Context 拥有如此多的数据将驱动整个应用程序的设计,无论所有对象是否都直接意识到 Context 不管怎样。
调用者和被调用者访问参数字段的问题假定了一个非面向对象的范例。在oo中,对象更喜欢对自己拥有的数据进行操作。所以也许我能提供的最好的建议就是不要认为oop是“好”的,任何替代oop的方法都是“坏”的。这里的描述给人一个强烈的印象,这个应用程序不是面向对象的。这既不好也不坏,但是将oo设计模式混合到将数据与逻辑分离的应用程序中可能不会产生预期的结果。
你可以从函数式编程中找到灵感。

相关问题