Composition, Duck Typing, and Depending on a Shape

By the end of this lesson you can assemble an object from collaborators handed to it, depend on what those collaborators can do rather than on their types, and explain why that keeps the whole thing testable.

There is a common way for a small project to become hard to change. A base class collects behaviour, subclasses override pieces of it, and after four of them nobody can say what any particular instance actually does without reading five files in the right order.

Composition is the alternative: an object holds the parts it needs, and those parts are supplied when it is built. It is the same idea as Module 7's injected transport, and it produces the same benefit. A part you were given is a part a test can replace.

Python makes this cheaper than most languages, because a collaborator does not have to belong to any particular type. It only has to accept the calls you make on it.

Inheritance says "is a kind of". Composition says "has a" or "uses a". The practical difference is that inheritance couples a subclass to everything about its parent, including things nobody meant to expose, while composition couples an object only to the calls it makes.

The usual advice, and it holds up: reach for composition first. Inheritance earns its place when several types genuinely share both behaviour and meaning, and even then, one level is almost always enough.

Compose by taking collaborators as constructor arguments:

class Pipeline:
    def __init__(self, loader, rule, reporter):
        self.loader = loader
        self.rule = rule
        self.reporter = reporter

Nothing here says what a loader is. It is whatever was passed, and the class's only requirement is that the calls it makes on it work.

That is duck typing: if it can be called the way you call it, it fits. The contract is the set of calls, not a declared type. The later Try it yourself version of Reporter needs something it can call with a record that returns a string, and a class instance's bound method, a plain function, and a lambda all satisfy that equally.

A protocol writes that contract down. typing.Protocol lets you declare a callable contract with a __call__(record) -> str method that a type checker can verify, without any class having to inherit from it. It is documentation with teeth, and it changes nothing at run time. For a project this size, a docstring naming the required calls is often enough; the value of the protocol appears once several implementations exist.

One rule follows directly, and it is the most useful thing in this lesson: do not check the type of a collaborator. An isinstance check inside a class is what removes the ability to substitute anything, which was the whole reason for composing. If a collaborator is wrong, the call it does not support will fail on its own, with a message naming the missing method.

class CsvWriter:
    def write(self, lines):
        return "\n".join(lines)


class MarkdownWriter:
    def write(self, lines):
        return "\n".join(f"- {line}" for line in lines)


class Reporter:
    """Renders records. `writer` is anything with write(lines) -> str."""

    def __init__(self, writer):
        self.writer = writer
        self.rendered = 0

    def report(self, records):
        lines = [f"{record['notice_id']},{record['amount']}" for record in records]
        self.rendered = len(lines)
        return self.writer.write(lines)


records = [{"notice_id": "A-1", "amount": 310000}, {"notice_id": "A-2", "amount": 128000}]

print(Reporter(CsvWriter()).report(records))
print(Reporter(MarkdownWriter()).report(records))


class CountingWriter:
    def __init__(self):
        self.calls = 0

    def write(self, lines):
        self.calls += 1
        return f"{len(lines)} lines"


spy = CountingWriter()
print(Reporter(spy).report(records), spy.calls)

Two writers with nothing in common except a write method taking a list of lines. Neither inherits from anything, and there is no shared base class at all.

Reporter never asks which writer it has. Its docstring states the contract in one line, which is the lightest version of a protocol.

CountingWriter is the point of the design. It is a test double: it satisfies the contract, records that it was called, and returns something trivially checkable. Writing it took three lines and needed no cooperation from Reporter.

Predict every printed line.

A-1,310000
A-2,128000
- A-1,310000
- A-2,128000
2 lines 1

Add a guard to the top of Reporter.__init__: if not isinstance(writer, CsvWriter): raise TypeError("writer must be a CsvWriter"). Predict what still works.

An assistant was asked to add Markdown output to a reporter. It produced this.

class BaseReporter:
    def __init__(self, records):
        self.records = records
        self.lines = self.build_lines()

    def build_lines(self):
        return [record["notice_id"] for record in self.records]

    def report(self):
        return "\n".join(self.lines)


class MarkdownReporter(BaseReporter):
    def __init__(self, records, bullet="-"):
        self.bullet = bullet
        super().__init__(records)

    def build_lines(self):
        return [f"{self.bullet} {record['notice_id']}" for record in self.records]


print(MarkdownReporter([{"notice_id": "A-1"}]).report())

AttributeError: 'MarkdownReporter' object has no attribute 'bullet'

class Reporter:
    def __init__(self, records, build_lines):
        self.records = records
        self.lines = build_lines(records)

    def report(self):
        return "\n".join(self.lines)


def markdown_lines(records, bullet="-"):
    return [f"{bullet} {record['notice_id']}" for record in records]


print(Reporter([{"notice_id": "A-1"}], markdown_lines).report())

Complete the reporter so it uses whatever formatter it was handed. Two very different collaborators must both work, unchanged.

Loading this exercise…

Optional: return to the Read the code writer example. Write its contract down as a typing.Protocol with a single write(lines) -> str method, and annotate that Reporter constructor with it, and confirm the code still runs unchanged, because protocols are not enforced at run time. Then write one sentence on what the protocol gives you that the docstring did not. The answer, that a type checker can now verify every call site without any class inheriting anything, is the whole case for them.

Sign in to track your progress on this exercise.

1. What does composition couple an object to, compared with inheritance?
2. What is duck typing, in terms of contracts?
3. Why is an isinstance check on an injected collaborator usually a mistake?
4. Why should a base class avoid calling an overridable method from __init__?

Sign in to track your progress on this exercise.

Prefer composition, hand collaborators in at construction, depend on the calls rather than the type, write the contract in a docstring or a protocol, and resist type checks that only remove substitutability. Next: putting a functional and an object-oriented version of the same feature side by side and choosing between them on evidence.