Think about two different ways a costume shop could organize its Halloween costumes. One way: sew a completely new, one-piece costume for every single character — a full Pirate Wizard costume, a full Pirate Ninja costume, a full Wizard Ninja costume — each one a single, inseparable garment from head to toe. The other way: keep a rack of separate, swappable pieces — hats, capes, boots, eye patches — that can be mixed and matched into any combination a customer wants, on the spot, without sewing anything new at all.

The second approach is obviously more practical, and it’s exactly the idea behind composition over inheritance. Rather than building a rigid family tree of specialized classes — a Wizard, a PirateWizard, a NinjaPirateWizard, each one a fixed, permanent combination — this principle encourages building small, focused, swappable pieces that can be combined together freely, the same way a costume shop combines separate pieces instead of sewing a new full costume for every possible combination.

To be clear from the start: this isn’t a rule that says “never use inheritance.” It’s a preference, a design habit, that says: when you’re deciding how to give an object new abilities, reach first for combining smaller, focused pieces together, and reach for a rigid parent-child class relationship only when it genuinely, clearly fits the situation.

It’s worth sitting with why this particular piece of advice has stayed so relevant for decades, even as programming languages and fashions have changed dramatically around it. Object-oriented programming’s earliest teaching materials leaned heavily on inheritance as the star of the show — elegant family trees of Animal, Dog, and Poodle classes were the standard way an entire generation of programmers first learned to think about code reuse. It took real, hard-won experience building large, long-lived systems for the industry to notice that those tidy classroom examples rarely survive contact with messy, evolving, real-world requirements — which is exactly the gap composition over inheritance was born to fill.

Formally speaking, composition over inheritance is a design principle suggesting that a class should achieve new behavior and code reuse by containing instances of other classes that implement the desired functionality, rather than by inheriting from a base class. It’s not a design pattern with a fixed structure like Decorator or Facade — it’s a broader guiding preference that shapes how many other patterns and habits get applied in practice.

Two ideas anchor this principle, and they’re worth holding onto through the rest of this guide:

• “Has-a” instead of “is-a.” Composition asks whether one object simply holds a reference to another — a car has an engine — rather than whether one object is fundamentally a specialized version of another — a sports car is a car.
• Behavior can be swapped at runtime. A composed object’s individual pieces can often be changed or replaced while a program is running, something a fixed inheritance hierarchy generally can’t do once an object has been created.

This preference gained particular fame from its inclusion in the influential 1994 Design Patterns book by the Gang of Four, which explicitly recommended favoring object composition over class inheritance wherever reasonably possible. The idea wasn’t brand new even then — experienced engineers had already been quietly discovering inheritance’s limitations through hard experience for years — but that book’s clear, memorable phrasing is largely what turned it into one of the most widely repeated pieces of advice in all of object-oriented design.

It’s worth noting that the Gang of Four’s own recommendation was more nuanced than the shortened, quotable phrase suggests. Their actual guidance acknowledged that inheritance remains a genuinely useful tool for certain relationships, and framed composition as the generally safer default — not an outright replacement. Over the years, as the phrase spread through blog posts, conference talks, and casual conversation, some of that original nuance got flattened into a blunter, more absolute-sounding rule than the original authors ever intended. Understanding the softer, original framing helps avoid treating the principle more rigidly than it was ever meant to be applied.

To understand why this principle became so popular, it helps to see exactly where inheritance, used too eagerly, starts causing real pain. Imagine modeling different kinds of birds using a class hierarchy.

birdHierarchy.tsclass Bird {
    fly() { /* flapping and soaring */ }
    makeSound() { /* generic bird sound */ }
}

class Eagle extends Bird {}
class Penguin extends Bird { // uh oh — penguins can't fly }

The moment Penguin extends Bird, it automatically inherits a fly() method that makes no biological sense at all. This is a famous, widely cited illustration of what’s often called the fragile base class problem — a parent class written with one set of assumptions in mind eventually meets a child class that breaks those assumptions, and there’s often no clean way to fix it without awkward workarounds, like overriding fly() to throw an error, or quietly do nothing at all.

This problem tends to compound as a hierarchy grows deeper and more specialized. A FlightlessBird subclass might get introduced to fix the Penguin problem, but then a genuinely flightless-but-still-partially-gliding bird shows up, not quite fitting either category cleanly. Real-world categories rarely sort themselves into the tidy, single-path family trees that inheritance assumes, and forcing them into one anyway tends to produce exactly this kind of awkward, ever-multiplying special-casing.

Composition sidesteps all of this by never assuming a rigid, single-path family tree in the first place. Instead of asking “what category does this thing permanently belong to,” it asks a much more flexible question: “what specific abilities does this thing currently need, and can I simply plug those in?”

There’s a subtler cost to overused inheritance worth naming too, beyond the well-known fragile base class problem: deep hierarchies make it genuinely hard to answer a simple question like “where does this behavior actually come from?” A method called on a deeply nested subclass might actually be defined four or five levels up the chain, in a grandparent class nobody currently working on the code has looked at in years. Composition avoids this kind of hidden, distant behavior almost entirely, since a composed object’s abilities are always sitting right there, explicitly held as named, visible pieces rather than silently inherited from somewhere far up an invisible chain.

The clearest way to decide between composition and inheritance in any given situation is to honestly ask which relationship actually describes reality: “is-a,” or “has-a.”

A genuinely reliable test: say the relationship out loud in a full sentence, using the actual words “is a” or “has a.” “A Penguin is a Bird” sounds perfectly natural — that’s a legitimate case for inheritance. “A Penguin has a Fly Behavior” sounds immediately awkward and wrong — which is exactly the clue that flying doesn’t belong baked into a shared parent class at all, and should instead be handled through composition, plugged in only for the birds that genuinely need it.

Let’s rebuild the bird example properly, using composition, with simple pseudocode that reads a lot like Java, C#, or TypeScript.

Step 1 — Describe abilities as separate, small interfaces

behaviors.tsinterface FlyBehavior { fly(): void }
interface SoundBehavior { makeSound(): void }

Step 2 — Build concrete implementations of each ability

implementations.tsclass FliesWithWings implements FlyBehavior {
    fly() { /* soar and flap */ }
}
class CannotFly implements FlyBehavior {
    fly() { /* stays firmly on the ground */ }
}
class SquawkSound implements SoundBehavior {
    makeSound() { /* a squawk */ }
}

Step 3 — Compose a Bird out of behaviors, instead of inheriting them

Bird.tsclass Bird {
    constructor(private flyBehavior: FlyBehavior, private soundBehavior: SoundBehavior) {}

    performFly() { this.flyBehavior.fly() }
    performSound() { this.soundBehavior.makeSound() }
}

Step 4 — Assemble any bird, with any combination of abilities

assembly.tsconst eagle = new Bird(new FliesWithWings(), new SquawkSound())
const penguin = new Bird(new CannotFly(), new SquawkSound())

Notice that Penguin never needed its own subclass at all, and it certainly never inherited a nonsensical fly() method that had to be awkwardly overridden. It simply received the correct combination of behaviors at the moment it was created — and if some future feature needed a bird to switch its flying ability while the program was already running, say, a bird recovering from an injury, that swap could happen just as easily too, something a fixed inheritance hierarchy could never offer.

Neither column represents “the right answer” in every situation — that’s precisely why this is called a preference rather than a rule. The guidance is simply to default toward the composition column first, and reach for the inheritance column only once a genuine, stable “is-a” relationship has been clearly confirmed.

Inheritance asks “what is this?” Composition asks “what can this currently do?”

Music production software offers a fitting everyday parallel. A digital audio workstation doesn’t offer a rigid “ReverbGuitarTrack” and a separate “DelayGuitarTrack” class for every possible effect combination — it lets a musician chain individual, swappable effect modules onto any track freely. Add a reverb module, add a delay module, remove the reverb later — all without needing a brand-new, specially named track type for every possible combination, exactly the same flexibility composition brings to code.

Furniture assembly offers one more grounded, physical parallel. A modular sofa system doesn’t require manufacturing a separate, uniquely molded piece of furniture for every possible room layout — a two-seat configuration, an L-shaped configuration, a U-shaped configuration. Instead, it offers individual modules — corner pieces, straight sections, ottomans — that snap together into whatever configuration a particular living room actually needs. The manufacturer builds a handful of well-designed pieces once, and customers compose nearly limitless layouts from them, which is precisely the economic and practical appeal composition offers a growing codebase too.

A useful gut-check question: “Am I confident this ‘is-a’ relationship will still make complete sense a year from now, no exceptions?” If the honest answer is a firm yes, a small, shallow inheritance relationship can be perfectly reasonable. If there’s genuine doubt — and with real-world categories, there very often is — composition offers a considerably safer, more adaptable starting point.

Depth matters just as much as certainty here. Even a genuinely valid “is-a” relationship can become risky once a hierarchy grows several levels deep — a Shape extended by Polygon extended by Quadrilateral extended by Rectangle extended by Square is technically accurate at every single step, yet the sheer depth of that chain makes any future change to a shared ancestor increasingly risky, the further down the tree its effects have to ripple. A shallow, one or two-level hierarchy built on a genuinely stable relationship tends to stay healthy far longer than a deep, many-level one, even when every individual link in that deep chain is technically correct.

Composing Everything, Even Genuinely Stable Hierarchies

Composition solves real problems, but applying it reflexively, even to a genuinely simple, stable “is-a” relationship, can add unnecessary interfaces and indirection for no real benefit. If a relationship is truly unlikely to ever need reconsidering, a small, shallow inheritance relationship remains a perfectly reasonable, simpler choice.

Deep Composition Chains That Are Hard to Follow

Just as inheritance can grow into an unmanageable, deep hierarchy, composition can grow into an equally unmanageable web of objects holding other objects holding other objects. Keeping composed relationships shallow and well-named prevents this from becoming its own tangled maze.

Forgetting Interfaces Entirely

Composition works best when composed pieces are described through general interfaces, not specific concrete classes — otherwise, much of the flexibility that made composition worthwhile in the first place quietly disappears, and swapping implementations becomes just as rigid as inheritance ever was.

Treating the Preference as an Absolute Rule

Some teams, having learned about inheritance’s real problems, swing too far and treat any inheritance at all as automatically wrong. This overcorrection can add needless complexity to genuinely simple, stable hierarchies that would have been perfectly well served by a small, shallow subclass.

It’s telling that several genuinely modern, carefully designed languages — Go and Rust among them — chose to omit traditional class inheritance entirely, favoring composition-first designs from the very start. That’s a meaningful signal about how the wider software community’s collective experience with inheritance’s pitfalls has shaped language design itself, not just individual coding habits within older languages that still offer both options.