Python Composition: Has-A vs Is-A

3Python Composition: explained step by step

When you want one class to reuse what another class already does, Python gives you two tools. Inheritance says a class is a kind of another class. Composition says a class has another object inside it and asks that object to do part of the work. Picking the right one early saves a lot of pain later.

The "is-a" and "has-a" test

Say the relationship out loud as a sentence:

• "A Manager is an Employee" sounds right, so inheritance fits.
• "A Car is an Engine" sounds silly. "A Car has an Engine" sounds right, so the car should hold an engine object.
• "An Order has order lines", "a Library has books", "a Playlist has songs": all composition.

A second test: if you inherit, the child gets every public method of the parent. Ask whether every one of them makes sense on the child. A car that suddenly has engine.rev() and engine.horsepower built in is a warning sign.

An object that holds other objects

Composition needs nothing new. Attributes can hold any value, including other objects. Pass the inner object into __init__, store it on self, and let the outer method delegate, which means it asks the inner object to do the real work:

class Engine:
    def __init__(self, horsepower):
        self.horsepower = horsepower
        self.running = False

    def start(self):
        self.running = True
        return f"engine with {self.horsepower} hp is running"

class Car:
    def __init__(self, model, engine):
        self.model = model
        self.engine = engine

    def start(self):
        return f"{self.model}: " + self.engine.start()

car = Car("Roadster", Engine(150))
print(car.start())
print(car.engine.running)

Car does not know how an engine starts. It only knows that its engine has a start() method. All engine details stay inside Engine, so a change there does not force a change in Car.

Small parts you can swap

Because Car just calls self.engine.start(), it works with any object that has a start() method. This is duck typing from the polymorphism lesson put to work: if it quacks like an engine, Car is happy. You can build a different car by passing a different part, or even swap the part later:

class PetrolEngine:
    def start(self):
        return "vroom"

class ElectricEngine:
    def start(self):
        return "hummmm"

class Car:
    def __init__(self, model, engine):
        self.model = model
        self.engine = engine

    def start(self):
        return f"{self.model} says {self.engine.start()}"

for engine in (PetrolEngine(), ElectricEngine()):
    print(Car("Roadster", engine).start())

pickup = Car("Pickup", PetrolEngine())
pickup.engine = ElectricEngine()
print(pickup.start())

With inheritance this would be much harder: Car would be tied to one parent for its whole life, and you would need a new subclass for every combination.

Refactoring a wrong inheritance

A very common trap is inheriting just to reuse code. Say you need a stack, where you may only add and remove at the top. Python's list already stores items, so class Stack(list) looks like a shortcut:

class Stack(list):
    def push(self, item):
        self.append(item)

pages = Stack()
pages.push("home")
pages.push("search")
pages.insert(0, "oops")
print(pages.pop())
print(pages.pop(0))

A Stack is not a list. It inherited dozens of methods such as insert, sort and pop(0) that let anyone break the "last in, first out" rule. The fix is to have a list instead of being one, and to offer only the methods a stack should have:

class Stack:
    def __init__(self):
        self._items = []

    def push(self, item):
        self._items.append(item)

    def pop(self):
        return self._items.pop()

    def peek(self):
        return self._items[-1]

    def __len__(self):
        return len(self._items)

pages = Stack()
pages.push("home")
pages.push("search")
print(pages.pop(), len(pages))
print(hasattr(pages, "insert"))

The list is now an implementation detail. You could replace it with a different structure tomorrow and nobody using Stack would notice.

Holding many objects

Often the inner part is a whole collection. An Order has many OrderLine objects. The outer class keeps them in a list it creates itself, and aggregate methods answer questions about the whole by asking each part:

class OrderLine:
    def __init__(self, product, unit_price, quantity):
        self.product = product
        self.unit_price = unit_price
        self.quantity = quantity

    def subtotal(self):
        return self.unit_price * self.quantity

class Order:
    def __init__(self, customer):
        self.customer = customer
        self.lines = []

    def add(self, product, unit_price, quantity=1):
        self.lines.append(OrderLine(product, unit_price, quantity))

    def total(self):
        return sum(line.subtotal() for line in self.lines)

order = Order("Asha")
order.add("notebook", 3.50, 2)
order.add("pen", 1.25, 4)
print(len(order.lines), order.total())

Order.total() does not repeat the price-times-quantity maths. It delegates that to each OrderLine. Each class stays small and has one job.

Composition over inheritance

Experienced programmers often say "favour composition over inheritance". The reasons are practical:

• A child is tied to its parent's internals; a change in the parent can break every child.
• Inheritance is decided when you write the class, composition can change while the program runs.
• Parts are easy to test on their own, and easy to replace with a simple stand-in.
• You expose only the methods you choose, instead of everything the parent has.

When inheritance is still the right tool

It is not a bad idea, just a narrower one. Use it when the child really is a specialised version of the parent and can be used anywhere the parent is expected: a Manager in code that handles Employee objects, or your own error class that extends Exception. Many designs use both: Employee(Person) is a person and has an address.

A good habit: start with composition. Reach for inheritance when you can honestly say "is a" and you want the polymorphism that comes with it.