Polymorphism and method overriding

Understand the concept

Polymorphism lets one operation work with different objects

A function can call a method shared by several objects without checking every concrete class. If the accepted objects each provide a suitable describe method, the caller can build a report through that interface. This style is often called duck typing: behavior relevant to the task matters more than a particular inheritance label.

The interface still has a contract. Does describe take no additional arguments? Does it return a string? Does it change state? A method having the same spelling is not enough if its behavior violates what the caller expects. Tests should include each intended object kind and a new compatible object that was not anticipated by the original caller.

Overriding replaces inherited behavior for a specialized class

An overridden method has the same name as a method inherited from a base class. Calling it on the specialized object finds the subclass implementation under normal attribute lookup. It may extend the base behavior with super, or implement the same interface differently.

Overriding is different from defining multiple same-name methods inside one class body. In ordinary Python, a later definition replaces the earlier binding. Python does not automatically choose a method based on the number or types of arguments as some languages do for signature-based overloading.

Optional arguments and explicit operations are clearer than imagined overloads

Use a default parameter when one operation genuinely has an optional input. Use different method names when the operations mean different things. Type-checking overload annotations document signatures for type checkers; they do not supply runtime dispatch implementations by themselves.

Python does support operator customization through special methods such as __add__, and there are separate dispatch utilities. Those are specific mechanisms with their own contracts, not evidence that repeated same-name method definitions dispatch automatically.

Worked example

class TopicNote:
    def __init__(self, topic):
        self.topic = topic

    def describe(self):
        return f"Note: {self.topic}"

class Timer:
    def __init__(self, minutes):
        self.minutes = minutes

    def describe(self):
        return f"Timer: {self.minutes} min"

def render_report(items):
    return "\n".join(item.describe() for item in items)

report = render_report([TopicNote("functions"), Timer(30)])
assert report == "Note: functions\nTimer: 30 min"
assert render_report([]) == ""
print(report)

These two classes do not inherit from one common application base, yet the reporting function accepts both through the documented describe interface. The fixture assumes validated constructor inputs; this lesson isolates interface behavior rather than duplicating every earlier validation example.

A separate example demonstrates the repeated-definition rule explicitly:

class Formatter:
    def format(self, text):
        return text

    def format(self, text, prefix):
        return prefix + text

formatter = Formatter()
assert formatter.format("hello", "note: ") == "note: hello"
try:
    formatter.format("hello")
except TypeError:
    print("Later definition replaced the earlier one")
else:
    raise AssertionError("There is no automatic signature overload here")

This deliberately flawed class is a diagnostic demonstration, not the recommended implementation. One format(self, text, prefix='') would support both documented call forms through one implementation.

Guided practice

1. Predict: add another compatible object with describe returning a string. Does render_report need a class-name check? Explain why it does not under this contract.
2. Modify: repair Formatter using a default prefix. Test both the one-argument and two-argument calls without defining format twice.
3. Reconstruct: write a report function that accepts any object with a zero-argument summary method returning text. Give it two unrelated kinds of objects and document that interface.

Do not catch every AttributeError from a polymorphic caller and substitute blank text. That could conceal an actual bug inside a method rather than an absent interface. If arbitrary external objects are allowed, define validation or adaptation deliberately.

Daily challenge

Create two object kinds, PlainTask and TimedTask, that both provide describe(detailed=False). PlainTask returns its title in either mode. TimedTask returns its title normally and title (minutes min) in detailed mode. Implement task_report(items, detailed=False) without inspecting class names or using an if chain for each type.

Use one implementation per method name in each class. This challenge tests a common interface and optional behavior, not signature-based overloading.

Reference solution

class PlainTask:
    def __init__(self, title):
        self.title = title

    def describe(self, detailed=False):
        return self.title

class TimedTask:
    def __init__(self, title, minutes):
        self.title, self.minutes = title, minutes

    def describe(self, detailed=False):
        return f"{self.title} ({self.minutes} min)" if detailed else self.title

def task_report(items, detailed=False):
    return "\n".join(item.describe(detailed=detailed) for item in items)

tasks = [PlainTask("Read"), TimedTask("Code", 45)]
assert task_report(tasks) == "Read\nCode"
assert task_report(tasks, True) == "Read\nCode (45 min)"
assert task_report([]) == ""

class ReviewCard:
    def describe(self, detailed=False):
        return "Review card"

assert task_report([ReviewCard()]) == "Review card"
print(task_report(tasks, True))

Debug and explain

If a previously supported call now raises a missing-argument TypeError, inspect whether a second definition replaced the first. If a report needs a new branch for every object type, inspect whether the shared interface is genuinely consistent. If a method returns a number where join expects text, inspect the interface contract rather than converting everything silently.

Explain polymorphism without saying “all classes have the same parent.” Then distinguish method overriding, optional arguments, and operator customization with one example each. Python's actual behavior should guide the terminology rather than an inaccurate diagram label.

Review and next step

Save the report tests and repaired Formatter. Rebuild the interface from memory at your next review. Day 23 uses standard-library date and time objects, applying your object-reading skills to useful types you did not define yourself.