-1

I have a Spring web service. When building the Response, our ResponseBuilder class uses a Context object. Every field on Response has its own associated business logic and [Name]FieldBuilder Singleton class, which operates on some information stored in Context. We want to avoid RequestScope and storing state in these classes in order to prevent Java from instantiating too many objects (we are working with >500tps at this time).

The Context object has Media, Campaigns, ClientInfo, etc. Inside each of these internal objects are further fields. Each Response field only needs some part of the information stored in Context.

From a design perspective, should I pass Context as-is to every FieldBuilder, and have them unpack it? Or should the unpacking be done in ResponseBuilder and the method signatures of the FieldBuilder be more specific?

Please let me know if more context is needed, thanks.

kzs
  • 141
  • 1
  • 13

1 Answers1

1

I think less context is needed (pun intended). The Context you've described will exhibit many of the problems of a god object even if it is a pure data structure without any logic. When so much data is put in one object, the only thing that object can do as the application grows is to grow along with it.

Eventually every method that does have business logic will require the Context as an argument. This will result in logic being implemented as functions or procedures, because there is no data to combine with it to create objects (all the data is owned by the Context).

You can try to mitigate this effect as you've described, by passing around pieces of the Context rather than the complete object. That's a good idea and I would recommend doing that; but it probably won't be the difference between OOP and procedural programming. Ultimately, the fact that a Context owns so much of the data will drive the design of the entire application, whether all the objects are directly aware of the Context or not.

The question of caller vs callee accessing argument fields presumes a non-object-oriented paradigm. In OO, objects prefer to act on data they own. So perhaps the best advice I can offer is to step back from the idea that OOP is "good" and any alternative to OOP is "bad". The description here gives a strong impression that this application is not OO. And that's neither good nor bad, but mixing OO design patterns into an application that separates data from logic may not produce the intended results.

You may find inspiration investigating Functional Programming.

jaco0646
  • 15,303
  • 7
  • 59
  • 83
  • Thanks for your insightful comment. We are indeed doing things in a procedural manner now, and as you've said, it's not necessarily ~bad~. But I guess we could either try to make things object oriented, or we could go the FP route and double down on the procedural nature of our response. What exactly do you mean by an application that "separates data from logic" though? – kzs Feb 17 '21 at 08:01
  • Additionally, is breaking down the `Context` object into individual objects another path? I feel that it actually is the same difference as passing around pieces of `Context` anyway... So even without a "god object" the problem would still stand. – kzs Feb 17 '21 at 09:33
  • Dividing the `Context` into individual data structures will not make it any less procedural, as long as it remains separate from the business logic; but I think every paradigm prefers small cohesive pieces versus the opposite. – jaco0646 Feb 17 '21 at 17:18