Composition and inheritance

One fix, a thousand wrong receipts

• A shop adds a loyalty bonus to its receipt total. The next day every discount receipt is wrong, though nobody touched the discount code.
• The discount class had copied the old total code instead of reusing it. How classes connect decides whether a fix in one place stays a fix everywhere.

Two ways to connect classes

• Inheritance 继承 says is-a: a Member is a Person. Composition 组合 says has-a: a Library has a Catalog.
• Inheritance ties classes tightly. When a change to a base class breaks its children, that is the fragile base class 脆弱基类 problem.

super() builds the base first

• super().__init__(...) runs the base class's set-up first, so Person.__init__ finishes before any Member line runs. Skip it and self._name does not exist when Member needs it.

class Member(Person):
    def __init__(self, name, card):
        super().__init__(name)
        self._card = card
        self._loans = 0

Override by delegating

• To change a base method, call it and adjust the result: return super().total() - 10. The base's loyalty bonus then stays in your total.
• Copying the base's code into the override makes a fork. The day the base gains a line, the copy goes stale: that was the receipt bug.

Composition delegates

• A Library holds its Copy objects and passes questions on: available() asks each part not c.is_out() and counts the answers.
• The library holds no borrowing logic of its own. Each part keeps its own rules.

Swap the part, keep the whole

• Replace the list of copies with a database-backed collection and Library does not change: parts change, the whole keeps its interface.
• Rule of thumb: inheritance for a true is-a, composition for everything else.

Worked example: building and counting

Three common slips

Recap