OOP ABAP Part 7: Composition vs Inheritance

📌 KEY POINTS
✅ Inheritance models "is-a" (a business ticket IS a ticket); composition models "has-a" (a booking HAS a pricing strategy).
✅ Composition: an object holds references to helper objects and delegates work to them.
✅ Prefer composition for reuse; use inheritance only for a true, stable is-a relationship.
⚠️ Deep hierarchies make changes to a superclass risky for all subclasses (fragile base class).

━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 3 showed inheritance. It is powerful but often overused for code reuse. This lesson shows the alternative.

━━━━━━━━━━━━━━━━━━━━
▶ 1. THE PROBLEM WITH INHERITANCE FOR REUSE
A team builds lcl_order_base → lcl_order_with_pricing → lcl_order_with_pricing_and_tax → lcl_export_order. Every new combination (export without tax, domestic with special pricing) needs another subclass. A change in lcl_order_base affects all of them. ABAP allows only one superclass, so combining two capabilities by inheritance is impossible.

━━━━━━━━━━━━━━━━━━━━
▶ 2. COMPOSITION AND DELEGATION
Instead, the order class has attributes:

• mo_pricing TYPE REF TO lif_pricing
• mo_tax TYPE REF TO lif_tax

The order calls mo_pricing->calculate( ) and mo_tax->calculate( ). Different behaviour comes from passing different objects, not from different subclasses.

━━━━━━━━━━━━━━━━━━━━
▶ 3. BENEFITS

• Combine behaviours freely (any pricing with any tax).
• Replace parts at runtime or in tests (fake tax calculator).
• Changes stay local to one small class.
• Each part has a single responsibility and can be tested alone.

━━━━━━━━━━━━━━━━━━━━
▶ 4. WHEN INHERITANCE IS RIGHT

• True is-a with shared structure and behaviour, stable over time.
• Framework requirements: exception classes inherit from CX_STATIC_CHECK, some SAP frameworks expect subclassing of an abstract base (e.g. template-method pattern).
• Abstract class with shared frame and small specific steps.

━━━━━━━━━━━━━━━━━━━━
▶ 5. RULES OF THUMB

• "Can I say X is a Y in all situations?" If not → composition.
• Hierarchies deeper than 2–3 levels → reconsider.
• Mark classes FINAL by default; open them for inheritance consciously.

━━━━━━━━━━━━━━━━━━━━
▶ 6. REFACTORING A HIERARCHY
Identify the varying behaviours → create an interface for each → move each variant into its own class → give the main class references to them → create objects in a factory (Part 8).

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

1. Run the code example: one order class with two different pricing objects.
2. Add a new tax implementation without changing lcl_order.
3. Write down what the inheritance version would need.

✅ CHECKPOINT: you prefer composition for reuse and can justify when inheritance is appropriate.

A freight calculation framework had grown to 14 subclasses (road, road-express, road-hazardous, sea, sea-hazardous …). Adding "rail with hazardous surcharge" required copying code from two branches because ABAP has single inheritance.
The team refactored into one freight class composed of three strategies: transport mode, surcharge rules and currency rounding. The 14 subclasses became 9 small FINAL classes that can be combined freely, and unit tests cover each strategy separately.

• Using inheritance just to reuse a few methods.
• Deep hierarchies where every combination is a new subclass.
• Subclasses that depend on protected internals of the superclass.
• Leaving classes open (non-final) without a reason.
• Composing concrete classes instead of interfaces.

• Prefer composition + interfaces for varying behaviour.
• Use inheritance for stable is-a relationships and framework base classes.
• Keep hierarchies shallow.
• Inject composed objects via constructor.
• Mark classes FINAL by default.

Questions: "Composition or inheritance — how do you decide?", "What is the fragile base class problem?", "How do you combine behaviours with single inheritance?"
Strong answer: inheritance for true is-a relationships; composition (has-a) with delegation to interface-typed helper objects for varying behaviour; single inheritance and fragile base classes make deep hierarchies risky; composition allows free combination, runtime replacement and test doubles.