Size of rollup class

[pgonzaleznetwork]

Hi there,

I was looking at the main rollup class for inspiration on good design patterns, etc. I noticed the class is 3K+ lines long. There are likely multiple responsibilities and reasons to change here.

Is there a specific reason or limitation that forced the logic to be in one place instead of brown down into smaller classes? Thanks 🙏

[jamessimone]

It's a constant tradeoff with packaging, particularly as the primary rollup class is the facade for both apex and flow-based entry points.

I don't think any package author enjoys having a large main entry point, but the alternatives aren't always better (in my opinion).

[pgonzaleznetwork]

Thanks. I'm trying to understand what is the tradeoff here. If you broke this down into smaller classes, what capability would you lose? Again, just looking for inspiration :)

[jamessimone]

Packages with a large number of Apex classes tend to be looked down upon. Furthermore, in this specific case the responsibility - such as it is - of some of the larger classes is still well-defined.

For instance, only subclasses of Rollup care about the inner class CalcItemBag, which allows them to reference it without specifying the outer class name. Such a thing wouldn't be possible if it were promoted to an outer class; this creates coupling where there was none, previously, and puts more pressure (than there already is) on the reader, as the horizontal columnar depth is already quite large (because I've heard quite a bit of feedback from package subscribers indicating they're strongly in favor of the Rollup preface on class names, which serves to group the package classes accordingly in any subscriber org - so renaming something that used to be just CalcItemBag to RollupCalcItemBag creates depth pressure within each of the classes in addition to the coupling I've mentioned above).

If this weren't code being packaged, it would be a lot easier to manage many of the self-contained responsibilities that make some of the larger classes in this repo large to begin with. All of the querying behavior, for instance, would simply be using my DML mocking library. That would save quite a few lines of code in the existing Rollup class.

Still, Rollup would easily exceed a thousand lines with simply the global static methods that serve as the entry point for the package, and there is no way to get around that - nor is there any reason to. It's important to understand that while smaller classes can be preferred in many instances, they should not be preferred as a means of arbitrarily trying to reduce LOC length. It would be like trying to reduce the complexity of a spark plug by stripping it down into its constituent components; it might make for better organization, but it'd also prevent you from using the spark plug for its intended purpose without putting it back together.

At the moment, I'm content with the idea that Rollup has all of the synchronous parts of the act of invoking a rollup operation within it, and that it delegates to RollupAsyncProcessor and RollupFullRecalcProcessor as is necessary. It's a simple mental model that serves to encapsulate the complexities within the rest of the code.