#25 When One Class Is Not Enough ​

Every example in this series is one class, and for the screens it is about that is the right size. Real applications grow past it — and the honest question is what the seams are, because a framework that has no answer here produces one 4,000-line class and a maintainer who resigns.

There are four seams, and each one is ordinary ABAP.

One class per screen. The unit of an abap2UI5 app is a screen with the logic behind it. A master list and a detail screen over different data are two classes, connected by the stack from #18: the list calls the detail with nav_app_call( ), the detail returns with nav_app_leave( ), and the list reads the result through get_app_prev( ). Each class is small enough to read, and each has a main( ) of its own.

Popups and value helps as classes. A confirmation dialog, a value help, a settings popup used from several screens — each is a z2ui5_if_app that displays into the popup slot. Written once, called from anywhere, tested on its own.

The logic in a class that has no screen. A zcl_invoice_service with read( ), validate( ) and post( ) is where the business logic goes when a second screen needs it, or a batch job does, or a test does. The app class becomes what a dynpro program's PAI modules were: it takes the event, calls the service, updates the attributes. One thing to know, and it is the sort of thing that is obvious in hindsight: a reference held in an attribute is serialized with the instance, so a helper either implements if_serializable_object and stays small, or is created fresh in every main( ) — which is usually the better answer anyway.

Parts of one screen as nested views. A master-detail layout, a tab strip, a side panel — nest_view_display( ) puts a view built in ABAP into a named slot of the main view, and rebuilds only that slot later. The page stands, the part changes.

One app, several classes: a screen per class, a service without a screen, a popup on the stack.

What does not appear in that list is a single framework concept. No component, no manifest, no router, no controller hierarchy, no dependency injection container. The seams are classes, method calls and one stack — which is exactly what a larger ABAP program has been made of for thirty years.

A larger app is more classes. The unit stayed the same size.