The enterprise software ecosystem lives under the spell of Enterprise JavaBeans (EJB 2.1) and Object-Oriented dogma pushed to parody. To persist a single invoice row to a relational table or validate a billing form, current orthodoxy dictates declaring a remote interface (EJBObject), a home interface (EJBLocalHome), an abstract entity implementation class (EntityBean), a two-hundred-line XML deployment descriptor, and heavy infrastructure inside application servers like WebLogic or WebSphere1 Rod Johnson exposed this productivity crisis in his landmark book Expert One-on-One J2EE Design and Development (2002), laying the foundation for what would become the Spring framework and the resurgence of POJOs (Plain Old Java Objects)..

What originally promised code reuse and modularity has devolved into a labyrinth of empty abstractions where actual business logic lies buried under endless strata of architectural plumbing.

The Pathology of the Fragile Base Class

The original sin of this trend lies in the veneration of inheritance as the primary mechanism for code reuse. Textbooks taught developers to model systems by constructing real-world taxonomic trees: Vehicle yields Car, which yields ElectricCar.

In production software engineering, deep inheritance hierarchies suffer from the Fragile Base Class problem2 Barbara Liskov introduced the Liskov Substitution Principle (LSP) in 1987 to govern this precise risk: if a program expects an instance of type $T$, it must seamlessly operate with any subtype $S$ without breaking formal program correctness or requiring out-of-band domain knowledge.. A subclass does not merely inherit the public method signatures of its ancestor; it binds itself inextricably to the internal implementation mechanics of the superclass.

// Canonical example of inheritance fragility
public class InstrumentedHashSet<E> extends HashSet<E> {
    private int addCount = 0;

    @Override
    public boolean add(E e) {
        addCount++;
        return super.add(e);
    }

    @Override
    public boolean addAll(Collection<? extends E> c) {
        addCount += c.size();
        return super.addAll(c); // Danger! super.addAll() internally calls add()
    }
}

If the maintainer of the base HashSet class decides to implement addAll() by iterating and internally delegating to add(), the addCount counter silently doubles every added element. To fix this, the subclass author must dissect the private internals of the base class—shattering encapsulation—or pray that future runtime library upgrades do not corrupt system state.

Pattern Inflation and Lost Domain Context

The enterprise community responded to inheritance failures not by simplifying, but by piling on more abstractions. The Gang of Four (GoF) catalog ceased to be a pragmatic toolset of Smalltalk and C++ design heuristics, morphing instead into bureaucratic dogma.

Grotesque constructs emerged where a basic ledger transaction required an AbstractTransactionProcessorFactory, wrapped inside a TransactionPolicyProxyDecorator, coordinated through a CommandExecutionChainManager. Computing semantics vanished behind interface scaffolding:

Data In ──> [Proxy] ──> [Interceptor] ──> [Adapter] ──> [Facade] ──> [Worker]
                              ▲
               Where is the actual business rule?

When an engineer tasked with debugging a failed wire transfer must step through twelve intermediate delegation layers that do nothing but hand the payload to the next interface, the design is no longer taming essential complexity; it is manufacturing accidental complexity to justify its own architecture3 Fred Brooks distinguished essential complexity (inherent to the real-world problem domain) from accidental complexity (introduced by engineering tooling and developer choices) in No Silver Bullet (1986)..

Composition Over Inheritance and Returning to the Data

Escaping this bog does not require exotic programming paradigms; it requires honoring the most neglected maxim from the GoF authors themselves: favor object composition over class inheritance.

Instead of inheriting behavior through a rigid type hierarchy, decoupled software assembles decoupled components via explicit references. If a class needs to instrument container metrics, it does not inherit from HashSet: it holds a private Set reference and delegates strictly the operations it intends to modify:

// Clean composition via explicit delegation
public class InstrumentedSet<E> implements Set<E> {
    private final Set<E> internalSet;
    private int addCount = 0;

    public InstrumentedSet(Set<E> internalSet) {
        this.internalSet = internalSet;
    }

    public boolean add(E e) {
        addCount++;
        return internalSet.add(e);
    }

    public boolean addAll(Collection<? extends E> c) {
        addCount += c.size();
        return internalSet.addAll(c);
    }
    // ... remaining interface methods cleanly delegated ...
}

Composition replaces rigid compile-time inheritance with explicit runtime contracts. The wrapper assumes nothing regarding the private mechanics of the underlying instance; it respects strictly the public interface.

The collapse of EJB monoliths and early-2000s taxonomic excess offers a stark lesson: software does not exist to erect cathedrals of abstract classes attempting to categorize the universe. It exists to transform input data into output data with minimal cognitive friction. Every layer of abstraction that does not solve a concrete problem in the domain is technical debt introduced by design.