Python Polymorphism and Method Overriding: Building Flexible and Extensible Code

Introduction

Imagine you’re building a music player application. You have different audio formats: MP3, WAV, and FLAC. Each format needs to be played differently, but your player should work seamlessly with all of them without knowing the specific details of each format. This is where polymorphism comes in.

Polymorphism, derived from Greek words meaning “many forms,” is a core principle of object-oriented programming that allows objects of different types to be treated through the same interface. In Python, polymorphism enables you to write flexible, extensible code that works with multiple types without needing to know their specific implementations.

In this guide, we’ll explore polymorphism and method overriding—two interconnected concepts that form the foundation of flexible Python code. You’ll learn how to design classes that work together seamlessly, understand Python’s unique approach to polymorphism through duck typing, and discover practical patterns you can apply to your own projects.

Part 1: Understanding Polymorphism

What Is Polymorphism?

Polymorphism is the ability of objects to take on multiple forms or for functions to work with objects of different types. In Python, it means you can call the same method on different objects, and each object responds according to its own implementation.

Why Polymorphism Matters

Polymorphism provides several critical benefits:

Flexibility: Write code that works with multiple types without modification
Extensibility: Add new types without changing existing code
Maintainability: Reduce code duplication and complexity
Loose coupling: Objects don’t need to know about each other’s specific implementations
Scalability: Build systems that grow without becoming unwieldy

Types of Polymorphism

Python supports different forms of polymorphism:

Compile-time polymorphism (Method overloading): Not directly supported in Python, but achievable through default arguments or *args
Runtime polymorphism (Method overriding): Achieved through inheritance and method overriding
Duck typing: Python’s unique approach—“if it walks like a duck and quacks like a duck, it’s a duck”

Part 2: Method Overriding

What Is Method Overriding?

Method overriding occurs when a child class provides its own implementation of a method that’s already defined in the parent class. The child’s implementation replaces the parent’s implementation for objects of the child class.

Basic Method Overriding

# Parent class
class Animal:
    def speak(self):
        print("Animal makes a sound")
    
    def move(self):
        print("Animal moves")

# Child class overrides speak() method
class Dog(Animal):
    def speak(self):
        print("Dog barks: Woof!")
    
    # Inherits move() from Animal

# Child class overrides both methods
class Fish(Animal):
    def speak(self):
        print("Fish bubbles")
    
    def move(self):
        print("Fish swims")

# Demonstrate polymorphism
animals = [Dog(), Fish(), Animal()]

for animal in animals:
    animal.speak()  # Each animal speaks differently
    animal.move()   # Each animal moves differently

# Output:
# Dog barks: Woof!
# Animal moves
# Fish bubbles
# Fish swims
# Animal makes a sound
# Animal moves

This example demonstrates runtime polymorphism: the same method call (speak() and move()) produces different results depending on the object’s type.

Overriding with Different Signatures

class Vehicle:
    def start(self):
        print("Vehicle starting...")

class Car(Vehicle):
    def start(self, engine_type="gasoline"):
        print(f"Car starting with {engine_type} engine...")

class ElectricCar(Vehicle):
    def start(self, battery_level=100):
        if battery_level > 20:
            print(f"Electric car starting (Battery: {battery_level}%)")
        else:
            print("Battery too low to start")

# Use the classes
car = Car()
car.start()                    # Output: Car starting with gasoline engine...
car.start("diesel")            # Output: Car starting with diesel engine...

electric = ElectricCar()
electric.start()               # Output: Electric car starting (Battery: 100%)
electric.start(15)             # Output: Battery too low to start

Part 3: Using `super()` in Method Overriding

The `super()` Function

super() allows you to call methods from the parent class while in a child class. This is essential when you want to extend parent functionality rather than completely replace it.

class Employee:
    def __init__(self, name, salary):
        self.name = name
        self.salary = salary
    
    def get_info(self):
        return f"Name: {self.name}, Salary: ${self.salary}"
    
    def give_raise(self, amount):
        self.salary += amount
        print(f"{self.name} received a raise of ${amount}")

class Manager(Employee):
    def __init__(self, name, salary, department):
        super().__init__(name, salary)  # Call parent's __init__
        self.department = department
    
    def get_info(self):
        # Call parent's get_info and extend it
        parent_info = super().get_info()
        return f"{parent_info}, Department: {self.department}"
    
    def give_raise(self, amount, bonus=0):
        # Call parent's give_raise and add bonus logic
        super().give_raise(amount)
        if bonus > 0:
            self.salary += bonus
            print(f"Manager {self.name} received bonus of ${bonus}")

# Use the classes
employee = Employee("Alice", 50000)
print(employee.get_info())
# Output: Name: Alice, Salary: $50000

manager = Manager("Bob", 70000, "Engineering")
print(manager.get_info())
# Output: Name: Bob, Salary: $70000, Department: Engineering

manager.give_raise(5000, bonus=2000)
# Output:
# Bob received a raise of $5000
# Manager Bob received bonus of $2000

Calling Parent Methods Explicitly

class Logger:
    def log(self, message):
        print(f"[LOG] {message}")

class FileLogger(Logger):
    def log(self, message):
        # Call parent method
        super().log(message)
        # Add file logging
        with open("app.log", "a") as f:
            f.write(f"{message}\n")

class ConsoleAndFileLogger(Logger):
    def log(self, message):
        # Call parent method
        super().log(message)
        # Add additional console formatting
        print(f"[CONSOLE] {message}")

# Use the loggers
logger = FileLogger()
logger.log("Application started")
# Output: [LOG] Application started
# (Also writes to app.log)

console_logger = ConsoleAndFileLogger()
console_logger.log("User logged in")
# Output:
# [LOG] User logged in
# [CONSOLE] User logged in

Part 4: Duck Typing - Python’s Approach to Polymorphism

What Is Duck Typing?

Duck typing is Python’s philosophy: “If it walks like a duck and quacks like a duck, it’s a duck.” In other words, Python doesn’t care about an object’s type—it cares about what methods and attributes it has.

# Different classes with the same interface
class Dog:
    def speak(self):
        return "Woof!"

class Cat:
    def speak(self):
        return "Meow!"

class Robot:
    def speak(self):
        return "Beep boop!"

# Function that works with any object that has a speak() method
def make_sound(creature):
    print(creature.speak())

# All these work without inheritance!
make_sound(Dog())      # Output: Woof!
make_sound(Cat())      # Output: Meow!
make_sound(Robot())    # Output: Beep boop!

Notice that Dog, Cat, and Robot don’t inherit from a common parent class. They work together because they all have a speak() method. This is duck typing in action.

Duck Typing with Collections

class FileWriter:
    def write(self, data):
        with open("output.txt", "w") as f:
            f.write(data)

class ConsoleWriter:
    def write(self, data):
        print(data)

class EmailWriter:
    def write(self, data):
        print(f"Sending email: {data}")

# Function that works with any writer
def save_data(writer, data):
    writer.write(data)

# Works with all writers
writers = [FileWriter(), ConsoleWriter(), EmailWriter()]
message = "Important data"

for writer in writers:
    save_data(writer, message)

# Output:
# Important data
# Sending email: Important data

Advantages of Duck Typing

# Duck typing allows flexible code
class DataProcessor:
    def process(self, data_source):
        # Works with any object that has a read() method
        data = data_source.read()
        return data.upper()

class FileReader:
    def read(self):
        return "data from file"

class APIReader:
    def read(self):
        return "data from api"

class DatabaseReader:
    def read(self):
        return "data from database"

processor = DataProcessor()

# All these work without modification
print(processor.process(FileReader()))
# Output: DATA FROM FILE

print(processor.process(APIReader()))
# Output: DATA FROM API

print(processor.process(DatabaseReader()))
# Output: DATA FROM DATABASE

Part 5: Practical Polymorphism Patterns

Pattern 1: Payment Processing System

class PaymentProcessor:
    def process_payment(self, amount):
        raise NotImplementedError("Subclasses must implement process_payment")

class CreditCardProcessor(PaymentProcessor):
    def __init__(self, card_number):
        self.card_number = card_number
    
    def process_payment(self, amount):
        print(f"Processing ${amount} with credit card {self.card_number[-4:]}")
        return True

class PayPalProcessor(PaymentProcessor):
    def __init__(self, email):
        self.email = email
    
    def process_payment(self, amount):
        print(f"Processing ${amount} via PayPal ({self.email})")
        return True

class CryptoCurrencyProcessor(PaymentProcessor):
    def __init__(self, wallet_address):
        self.wallet_address = wallet_address
    
    def process_payment(self, amount):
        print(f"Processing ${amount} in cryptocurrency to {self.wallet_address}")
        return True

# Checkout system that works with any processor
class Checkout:
    def __init__(self, processor):
        self.processor = processor
    
    def complete_purchase(self, amount):
        if self.processor.process_payment(amount):
            print("Purchase completed successfully!\n")

# Use different processors
processors = [
    CreditCardProcessor("1234-5678-9012-3456"),
    PayPalProcessor("[email protected]"),
    CryptoCurrencyProcessor("1A1z7agoat2wSEssSqBVxwwKHqr4GJCh2L")
]

for processor in processors:
    checkout = Checkout(processor)
    checkout.complete_purchase(99.99)

# Output:
# Processing $99.99 with credit card 3456
# Purchase completed successfully!
# 
# Processing $99.99 via PayPal ([email protected])
# Purchase completed successfully!
# 
# Processing $99.99 in cryptocurrency to 1A1z7agoat2wSEssSqBVxwwKHqr4GJCh2L
# Purchase completed successfully!

Pattern 2: Data Storage System

class DataStore:
    def save(self, key, value):
        raise NotImplementedError
    
    def load(self, key):
        raise NotImplementedError

class MemoryStore(DataStore):
    def __init__(self):
        self.data = {}
    
    def save(self, key, value):
        self.data[key] = value
        print(f"Saved to memory: {key}")
    
    def load(self, key):
        return self.data.get(key)

class FileStore(DataStore):
    def save(self, key, value):
        with open(f"{key}.txt", "w") as f:
            f.write(str(value))
        print(f"Saved to file: {key}")
    
    def load(self, key):
        try:
            with open(f"{key}.txt", "r") as f:
                return f.read()
        except FileNotFoundError:
            return None

class DatabaseStore(DataStore):
    def save(self, key, value):
        print(f"Saved to database: {key} = {value}")
    
    def load(self, key):
        print(f"Loaded from database: {key}")
        return "database_value"

# Application that works with any store
class Application:
    def __init__(self, store):
        self.store = store
    
    def save_user(self, user_id, user_data):
        self.store.save(f"user_{user_id}", user_data)
    
    def load_user(self, user_id):
        return self.store.load(f"user_{user_id}")

# Use different stores
stores = [MemoryStore(), FileStore(), DatabaseStore()]

for store in stores:
    app = Application(store)
    app.save_user(123, {"name": "Alice", "email": "[email protected]"})
    print()

# Output:
# Saved to memory: user_123
# 
# Saved to file: user_123
# 
# Saved to database: user_123 = {'name': 'Alice', 'email': '[email protected]'}

Part 6: Best Practices and Pitfalls

Best Practice 1: Use Abstract Base Classes

from abc import ABC, abstractmethod

class Shape(ABC):
    """Abstract base class for shapes"""
    
    @abstractmethod
    def area(self):
        pass
    
    @abstractmethod
    def perimeter(self):
        pass

class Circle(Shape):
    def __init__(self, radius):
        self.radius = radius
    
    def area(self):
        return 3.14159 * self.radius ** 2
    
    def perimeter(self):
        return 2 * 3.14159 * self.radius

class Rectangle(Shape):
    def __init__(self, width, height):
        self.width = width
        self.height = height
    
    def area(self):
        return self.width * self.height
    
    def perimeter(self):
        return 2 * (self.width + self.height)

# Can't instantiate abstract class
# shape = Shape()  # TypeError

# Can instantiate concrete classes
shapes = [Circle(5), Rectangle(4, 6)]

for shape in shapes:
    print(f"Area: {shape.area():.2f}, Perimeter: {shape.perimeter():.2f}")

# Output:
# Area: 78.54, Perimeter: 31.42
# Area: 24.00, Perimeter: 20.00

Best Practice 2: Maintain Liskov Substitution Principle

The Liskov Substitution Principle states that objects of a superclass should be replaceable with objects of its subclasses without breaking the application.

# Good: Follows LSP
class Bird:
    def move(self):
        pass

class Sparrow(Bird):
    def move(self):
        print("Sparrow flies")

class Penguin(Bird):
    def move(self):
        print("Penguin swims")

# Bad: Violates LSP
class FlyingBird(Bird):
    def fly(self):
        print("Flying...")

class Ostrich(FlyingBird):
    def fly(self):
        raise NotImplementedError("Ostriches can't fly!")

# Better: Separate concerns
class SwimmingBird(Bird):
    def swim(self):
        print("Swimming...")

class Penguin(SwimmingBird):
    def move(self):
        self.swim()

Pitfall 1: Inconsistent Method Signatures

# Bad: Inconsistent signatures
class DataProcessor:
    def process(self, data):
        pass

class CSVProcessor(DataProcessor):
    def process(self, data, delimiter=","):  # Different signature!
        pass

class JSONProcessor(DataProcessor):
    def process(self, data, strict=True):  # Different signature!
        pass

# Good: Consistent signatures
class DataProcessor:
    def process(self, data, **options):
        pass

class CSVProcessor(DataProcessor):
    def process(self, data, **options):
        delimiter = options.get("delimiter", ",")
        print(f"Processing CSV with delimiter: {delimiter}")

class JSONProcessor(DataProcessor):
    def process(self, data, **options):
        strict = options.get("strict", True)
        print(f"Processing JSON (strict={strict})")

Pitfall 2: Breaking Parent Contracts

# Bad: Child breaks parent's contract
class Stack:
    def push(self, item):
        pass
    
    def pop(self):
        pass

class LimitedStack(Stack):
    def __init__(self, max_size):
        self.max_size = max_size
        self.items = []
    
    def push(self, item):
        if len(self.items) >= self.max_size:
            raise Exception("Stack is full")  # Breaks contract!
        self.items.append(item)
    
    def pop(self):
        if not self.items:
            raise Exception("Stack is empty")  # Breaks contract!
        return self.items.pop()

# Good: Maintain contract
class LimitedStack(Stack):
    def __init__(self, max_size):
        self.max_size = max_size
        self.items = []
    
    def push(self, item):
        if len(self.items) < self.max_size:
            self.items.append(item)
    
    def pop(self):
        if self.items:
            return self.items.pop()
        return None

Pitfall 3: Over-Engineering with Polymorphism

# Bad: Unnecessary polymorphism
class Operation:
    def execute(self):
        pass

class AddOperation(Operation):
    def execute(self):
        return 2 + 2

class SubtractOperation(Operation):
    def execute(self):
        return 5 - 3

# Good: Simple and direct
def add():
    return 2 + 2

def subtract():
    return 5 - 3

# Use polymorphism when you have multiple implementations
# that need to be used interchangeably

Part 7: Polymorphism vs Duck Typing

When to Use Inheritance-Based Polymorphism

# Use inheritance when there's a clear "is-a" relationship
class Vehicle:
    def start(self):
        pass

class Car(Vehicle):
    def start(self):
        print("Car engine starts")

class Motorcycle(Vehicle):
    def start(self):
        print("Motorcycle engine starts")

When to Use Duck Typing

# Use duck typing when you just need objects with certain methods
class FileLogger:
    def log(self, message):
        with open("log.txt", "a") as f:
            f.write(message + "\n")

class ConsoleLogger:
    def log(self, message):
        print(message)

class EmailLogger:
    def log(self, message):
        print(f"Email: {message}")

# Works with any object that has a log() method
def log_event(logger, event):
    logger.log(event)

Conclusion

Polymorphism and method overriding are powerful tools for building flexible, maintainable Python code. They enable you to write code that works with multiple types without modification, making your applications more extensible and easier to maintain.

Key takeaways:

Polymorphism allows objects of different types to be treated through the same interface
Method overriding enables child classes to provide their own implementations of parent methods
super() lets you call parent methods while extending functionality
Duck typing is Python’s unique approach—focus on what objects can do, not their type
Abstract base classes define contracts that subclasses must fulfill
Liskov Substitution Principle ensures subclasses can replace parent classes safely
Use inheritance for clear “is-a” relationships
Use duck typing for flexible, loosely-coupled code
Avoid over-engineering—use polymorphism when it solves real problems

Start by identifying places in your code where you have similar logic repeated for different types. These are opportunities to apply polymorphism. As you practice, you’ll develop an intuition for when and how to use these patterns effectively.

Remember: the goal of polymorphism is to write code that’s flexible, maintainable, and easy to extend. Use it wisely, and your code will be more elegant and professional.

Happy coding!