我有一个springweb服务。在构建 Response
,我们的 ResponseBuilder
类使用 Context
对象。每一个领域 Response
有自己的关联业务逻辑和
[Name]FieldBuilder Singleton
类,它对存储在 Context
. 我们想避免 RequestScope
并将状态存储在这些类中,以防止java示例化过多的对象(目前我们使用的是>500tps)。
这个 Context
对象具有 Media
, Campaigns
, ClientInfo
,等等。每个内部对象中都有进一步的字段。每个 Response
字段只需要存储在 Context
.
从设计的Angular 来看,我应该通过吗 Context
对每一个 FieldBuilder
,然后让他们打开 Package ?或者开箱是在 ResponseBuilder
以及 FieldBuilder
具体点?
请让我知道如果需要更多的上下文,谢谢。
1条答案
按热度按时间wlp8pajw1#
我认为需要较少的上下文(双关语)。这个
Context
您所描述的将展示上帝对象的许多问题,即使它是没有任何逻辑的纯数据结构。当这么多数据放在一个对象中时,随着应用程序的增长,对象唯一能做的就是随着它一起增长。最终,每个具有业务逻辑的方法都需要
Context
作为论据。这将导致逻辑被实现为函数或过程,因为没有数据可以与之结合来创建对象(所有数据都属于Context
).正如您所描述的,您可以通过传递
Context
而不是完整的对象。这是个好主意,我建议你这样做;但这可能不是面向对象编程和过程编程之间的区别。最终,事实是Context
拥有如此多的数据将驱动整个应用程序的设计,无论所有对象是否都直接意识到Context
不管怎样。调用者和被调用者访问参数字段的问题假定了一个非面向对象的范例。在oo中,对象更喜欢对自己拥有的数据进行操作。所以也许我能提供的最好的建议就是不要认为oop是“好”的,任何替代oop的方法都是“坏”的。这里的描述给人一个强烈的印象,这个应用程序不是面向对象的。这既不好也不坏,但是将oo设计模式混合到将数据与逻辑分离的应用程序中可能不会产生预期的结果。
你可以从函数式编程中找到灵感。