Lesson 6: Object-Oriented Programming

Learning Objectives#

By the end of this lesson, you will be able to:

1. Define and implement classes and objects using proper encapsulation techniques to create well-structured, maintainable code
2. Apply the four pillars of OOP—encapsulation, abstraction, inheritance, and polymorphism—to solve real-world software design challenges
3. Design class hierarchies that effectively use inheritance to promote code reuse while avoiding common pitfalls like tight coupling
4. Implement polymorphism through method overriding and interfaces to create flexible, extensible systems
5. Evaluate when to use composition over inheritance and apply appropriate design patterns to create robust object-oriented solutions

Introduction#

Object-oriented programming (OOP) represents a fundamental paradigm shift in how we think about and structure software. Rather than viewing programs as sequences of instructions operating on data, OOP organizes code around “objects”—self-contained entities that bundle data and the operations that work with that data. This approach more naturally models real-world concepts and creates systems that are easier to understand, maintain, and extend [1].

The power of OOP lies in its four fundamental principles: encapsulation (bundling data with methods), abstraction (hiding complexity), inheritance (creating relationships between classes), and polymorphism (treating related objects interchangeably). These principles work together to address the core challenges of software development: managing complexity, promoting code reuse, and enabling systems to evolve gracefully as requirements change [2].

Since its emergence in the 1960s with languages like Simula, OOP has become the dominant programming paradigm. Modern languages including Python, Java, C++, JavaScript, and C# all provide robust OOP capabilities. Understanding OOP is essential for working with contemporary frameworks, design patterns, and architectural approaches. Whether you’re building web applications, mobile apps, or distributed systems, OOP principles provide the foundation for creating professional, maintainable code [3].

In this lesson, we’ll explore each OOP principle in depth, examining both conceptual foundations and practical implementation. You’ll learn not just how to write object-oriented code, but when and why to apply specific techniques. We’ll also address common pitfalls and best practices that distinguish well-designed object-oriented systems from those that merely use classes without leveraging OOP’s full power.

Core Content#

Classes and Objects: The Foundation of OOP#

At the heart of object-oriented programming lies the distinction between classes and objects. A class is a blueprint or template that defines the structure and behavior of objects. An object (also called an instance) is a concrete realization of that class, with specific values for its attributes [1].

Think of a class as an architectural blueprint for a house, while objects are the actual houses built from that blueprint. The blueprint specifies what rooms the house will have and how they connect, but each house built from that blueprint has its own specific furniture, inhabitants, and color scheme.

Here’s a foundational example in Python:

class BankAccount:
    """Represents a bank account with deposit and withdrawal capabilities"""

    # Class attribute - shared by all instances
    bank_name = "Global Bank"
    account_count = 0

    def __init__(self, account_holder, initial_balance=0):
        """Initialize a new bank account"""
        # Instance attributes - unique to each object
        self.account_holder = account_holder
        self.balance = initial_balance
        self.account_number = BankAccount._generate_account_number()
        self.transaction_history = []

        # Update class-level counter
        BankAccount.account_count += 1

    def deposit(self, amount):
        """Add funds to the account"""
        if amount <= 0:
            raise ValueError("Deposit amount must be positive")

        self.balance += amount
        self.transaction_history.append({
            'type': 'deposit',
            'amount': amount,
            'balance_after': self.balance
        })
        return self.balance

    def withdraw(self, amount):
        """Remove funds from the account"""
        if amount <= 0:
            raise ValueError("Withdrawal amount must be positive")
        if amount > self.balance:
            raise ValueError("Insufficient funds")

        self.balance -= amount
        self.transaction_history.append({
            'type': 'withdrawal',
            'amount': amount,
            'balance_after': self.balance
        })
        return self.balance

    def get_balance(self):
        """Return current balance"""
        return self.balance

    @staticmethod
    def _generate_account_number():
        """Generate unique account number"""
        import random
        return f"ACC-{random.randint(10000, 99999)}"

    def __str__(self):
        """String representation of the account"""
        return f"{self.account_holder}'s account (#{self.account_number}): ${self.balance}"

# Creating objects from the class
account1 = BankAccount("Alice Smith", 1000)
account2 = BankAccount("Bob Johnson", 500)

# Each object has its own state
account1.deposit(250)  # Alice's account: $1250
account2.withdraw(100)  # Bob's account: $400

print(account1)  # Alice Smith's account (#ACC-12345): $1250
print(account2)  # Bob Johnson's account (#ACC-67890): $400
print(f"Total accounts: {BankAccount.account_count}")  # Total accounts: 2

This example demonstrates several key concepts:

Instance vs. Class Attributes: Instance attributes (like balance and account_holder) are unique to each object, while class attributes (like bank_name) are shared across all instances. Use class attributes for data that should be consistent across all objects [1].

Methods: Functions defined inside a class are called methods. They operate on the object’s data and define the object’s behavior. The self parameter (called this in languages like Java and JavaScript) refers to the current instance [2].

Initialization: The __init__ method (constructor) is called automatically when creating a new object. It sets up the object’s initial state. Different languages have different syntax—__init__ in Python, constructors with the class name in Java and C++, constructor() in JavaScript [1].

Encapsulation Foundation: Notice how the account’s balance can only be modified through the deposit() and withdraw() methods, not directly. This is the beginning of encapsulation, which we’ll explore more deeply next.

Encapsulation: Protecting Data Integrity#

Encapsulation is the principle of bundling data (attributes) and the methods that operate on that data together in a single unit (the class) while restricting direct access to internal state [2]. This creates a clear boundary between an object’s public interface (what other code can use) and its private implementation (internal details that should be hidden).

Encapsulation serves three crucial purposes:

1. Data Protection: Prevents external code from putting the object into an invalid state
2. Implementation Hiding: Allows changing internal implementation without affecting code that uses the object
3. Controlled Access: Enables validation, logging, or side effects when data changes

Here’s a comprehensive example showing encapsulation in practice:

class Employee:
    """Represents an employee with encapsulated salary and personal information"""

    def __init__(self, name, employee_id, base_salary):
        # Public attribute - freely accessible
        self.name = name

        # Protected attribute (convention: single underscore)
        # Indicates "internal use" but not strictly enforced
        self._employee_id = employee_id

        # Private attribute (convention: double underscore)
        # Name mangling makes it harder to access from outside
        self.__base_salary = base_salary
        self.__bonus = 0

    # Property - provides controlled read access
    @property
    def employee_id(self):
        """Read-only access to employee ID"""
        return self._employee_id

    @property
    def salary(self):
        """Read-only access to total salary (base + bonus)"""
        return self.__base_salary + self.__bonus

    # Setter - provides controlled write access with validation
    @salary.setter
    def salary(self, new_base_salary):
        """Update base salary with validation"""
        if new_base_salary < 0:
            raise ValueError("Salary cannot be negative")
        if new_base_salary < self.__base_salary:
            raise ValueError("Cannot decrease base salary")

        self.__base_salary = new_base_salary

    def award_bonus(self, bonus_amount):
        """Add bonus to employee compensation"""
        if bonus_amount < 0:
            raise ValueError("Bonus must be positive")

        self.__bonus += bonus_amount
        print(f"{self.name} awarded bonus of ${bonus_amount}")

    def give_raise(self, percentage):
        """Increase base salary by percentage"""
        if percentage <= 0:
            raise ValueError("Raise percentage must be positive")

        increase = self.__base_salary * (percentage / 100)
        self.__base_salary += increase
        print(f"{self.name} received {percentage}% raise (${increase:.2f})")

    def get_total_compensation(self):
        """Calculate total compensation including benefits"""
        benefits = self.__base_salary * 0.15  # 15% benefits
        return self.__base_salary + self.__bonus + benefits

    def __str__(self):
        """String representation (doesn't expose private details)"""
        return f"Employee: {self.name} (ID: {self._employee_id})"

# Usage demonstrates encapsulation benefits
emp = Employee("Sarah Johnson", "EMP-001", 75000)

# Direct access to public attribute - allowed
print(emp.name)  # Sarah Johnson

# Access through property - controlled access
print(emp.salary)  # 75000

# Controlled modification through method - includes validation
emp.give_raise(10)  # Sarah Johnson received 10% raise ($7500.00)

# Property setter with validation
emp.salary = 85000  # Updates base salary with validation

# This would raise an error - validation protects data integrity
# emp.salary = -1000  # ValueError: Salary cannot be negative

# Cannot directly access private attribute (strongly discouraged)
# print(emp.__base_salary)  # AttributeError

# Internal state remains consistent
print(f"Total compensation: ${emp.get_total_compensation():.2f}")

This example illustrates encapsulation at work:

Access Control Levels: Python uses naming conventions to indicate intended access levels. Public attributes have no prefix, protected attributes use single underscore (_), and private attributes use double underscore (__). Other languages have explicit keywords: public, protected, private in Java and C++ [2].

Properties: Properties (called getters and setters in other languages) provide controlled access to attributes. They look like simple attribute access but can include validation, logging, or computed values. This is crucial for maintaining the object’s invariants [3].

Validation: Encapsulation enables enforcing business rules. The salary setter prevents negative values and salary decreases. The award_bonus() method validates positive bonuses. Without encapsulation, external code could set invalid values directly [2].

Implementation Flexibility: The salary property returns base_salary + bonus, but external code doesn’t know this. You could change the internal representation (maybe store total salary and calculate bonus differently) without affecting code that uses the salary property.

Abstraction: Managing Complexity#

While encapsulation hides implementation details behind a class, abstraction operates at a higher level—hiding entire implementation variations behind a common interface. Abstraction defines “what” an object does without specifying “how” it does it, allowing different implementations of the same interface [4].

Abstraction is implemented through abstract classes and interfaces. An abstract class defines a template for subclasses, including both abstract methods (that must be implemented) and concrete methods (that can be inherited). An interface (in languages that support them separately) defines a contract of methods that implementing classes must provide [4].

Here’s an example showing abstraction in Python using abstract base classes:

from abc import ABC, abstractmethod
from datetime import datetime

# Abstract base class - defines the interface
class PaymentProcessor(ABC):
    """Abstract interface for payment processing"""

    @abstractmethod
    def authorize_payment(self, amount, currency, payment_details):
        """Authorize payment - must be implemented by subclasses"""
        pass

    @abstractmethod
    def capture_payment(self, authorization_id):
        """Capture authorized payment - must be implemented"""
        pass

    @abstractmethod
    def refund_payment(self, transaction_id, amount):
        """Refund a payment - must be implemented"""
        pass

    # Concrete method - provides shared functionality
    def log_transaction(self, transaction_type, amount, status):
        """Log transaction - inherited by all subclasses"""
        timestamp = datetime.now().strftime("%Y-%m-%d %H:%M:%S")
        print(f"[{timestamp}] {transaction_type}: ${amount} - {status}")

# Concrete implementation for Stripe
class StripePaymentProcessor(PaymentProcessor):
    """Stripe-specific payment implementation"""

    def __init__(self, api_key):
        self.api_key = api_key
        self.api_version = "2023-10-16"

    def authorize_payment(self, amount, currency, payment_details):
        """Authorize payment through Stripe"""
        # Stripe-specific authorization logic
        print(f"Authorizing ${amount} {currency} via Stripe...")

        # Simulate API call
        authorization_id = f"stripe_auth_{hash(payment_details)}"
        self.log_transaction("Authorization", amount, "Success")

        return {
            'success': True,
            'authorization_id': authorization_id,
            'processor': 'stripe'
        }

    def capture_payment(self, authorization_id):
        """Capture Stripe payment"""
        print(f"Capturing Stripe payment: {authorization_id}")
        self.log_transaction("Capture", 0, "Success")
        return {'success': True, 'transaction_id': f"stripe_txn_{authorization_id}"}

    def refund_payment(self, transaction_id, amount):
        """Process Stripe refund"""
        print(f"Refunding ${amount} on Stripe transaction {transaction_id}")
        self.log_transaction("Refund", amount, "Success")
        return {'success': True, 'refund_id': f"stripe_ref_{transaction_id}"}

# Concrete implementation for PayPal
class PayPalPaymentProcessor(PaymentProcessor):
    """PayPal-specific payment implementation"""

    def __init__(self, client_id, secret):
        self.client_id = client_id
        self.secret = secret

    def authorize_payment(self, amount, currency, payment_details):
        """Authorize payment through PayPal"""
        # PayPal-specific authorization logic (different from Stripe)
        print(f"Creating PayPal order for ${amount} {currency}...")

        order_id = f"paypal_order_{hash(payment_details)}"
        self.log_transaction("Authorization", amount, "Pending")

        return {
            'success': True,
            'authorization_id': order_id,
            'processor': 'paypal',
            'approval_url': f"https://paypal.com/approve/{order_id}"
        }

    def capture_payment(self, authorization_id):
        """Capture PayPal payment"""
        print(f"Capturing PayPal order: {authorization_id}")
        self.log_transaction("Capture", 0, "Success")
        return {'success': True, 'transaction_id': f"paypal_txn_{authorization_id}"}

    def refund_payment(self, transaction_id, amount):
        """Process PayPal refund"""
        print(f"Refunding ${amount} on PayPal transaction {transaction_id}")
        self.log_transaction("Refund", amount, "Success")
        return {'success': True, 'refund_id': f"paypal_ref_{transaction_id}"}

# High-level code depends on abstraction, not implementation
class CheckoutService:
    """Checkout service using payment processor abstraction"""

    def __init__(self, payment_processor: PaymentProcessor):
        # Depends on abstraction - works with any PaymentProcessor
        self.processor = payment_processor

    def process_checkout(self, cart_total, currency, payment_details):
        """Process checkout using any payment processor"""
        print(f"\n=== Processing Checkout: ${cart_total} {currency} ===")

        # Same code works with Stripe, PayPal, or any future processor
        auth_result = self.processor.authorize_payment(
            cart_total, currency, payment_details
        )

        if auth_result['success']:
            capture_result = self.processor.capture_payment(
                auth_result['authorization_id']
            )

            if capture_result['success']:
                return {
                    'success': True,
                    'transaction_id': capture_result['transaction_id'],
                    'message': 'Payment successful'
                }

        return {'success': False, 'message': 'Payment failed'}

# Usage - swap implementations without changing checkout logic
stripe_checkout = CheckoutService(StripePaymentProcessor("sk_test_123"))
paypal_checkout = CheckoutService(PayPalPaymentProcessor("client_id", "secret"))

# Same interface, different implementations
result1 = stripe_checkout.process_checkout(99.99, "USD", {"card": "4242"})
result2 = paypal_checkout.process_checkout(149.99, "USD", {"email": "[email protected]"})

This abstraction provides powerful benefits:

Interface Consistency: CheckoutService doesn’t know or care whether it’s using Stripe or PayPal. It just calls the abstract methods defined in PaymentProcessor. This dramatically reduces coupling [4].

Extensibility: Adding support for a new payment processor (Bitcoin, Square, etc.) requires creating a new class that implements PaymentProcessor. No modifications to CheckoutService or existing payment processors are needed—a perfect example of the Open/Closed Principle [5].

Testability: You can create a mock payment processor for testing that implements PaymentProcessor without making real API calls. This makes unit testing straightforward and fast [3].

Substitutability: Any PaymentProcessor implementation can replace another without breaking code that depends on the abstraction. This is the Liskov Substitution Principle in action [5].

Inheritance: Modeling Relationships and Reusing Code#

Inheritance creates hierarchical relationships between classes, allowing a child class (subclass or derived class) to inherit attributes and methods from a parent class (superclass or base class). This enables code reuse and models “is-a” relationships where one class is a specialized version of another [1].

Inheritance is powerful but must be used carefully. Overuse creates rigid hierarchies that are difficult to modify. The key is recognizing when an inheritance relationship genuinely exists versus when composition (having an object as an attribute) is more appropriate [6].

Here’s an example showing effective inheritance:

class Vehicle:
    """Base class representing any vehicle"""

    def __init__(self, make, model, year):
        self.make = make
        self.model = model
        self.year = year
        self.odometer = 0

    def drive(self, distance):
        """Drive the vehicle a certain distance"""
        self.odometer += distance
        print(f"Drove {distance} miles. Total: {self.odometer} miles")

    def get_description(self):
        """Return vehicle description"""
        return f"{self.year} {self.make} {self.model}"

    def honk(self):
        """Make horn sound"""
        print("Beep beep!")

class Car(Vehicle):
    """Car is a specific type of vehicle"""

    def __init__(self, make, model, year, num_doors):
        # Call parent constructor
        super().__init__(make, model, year)
        # Add car-specific attribute
        self.num_doors = num_doors
        self.trunk_open = False

    def open_trunk(self):
        """Car-specific method"""
        self.trunk_open = True
        print("Trunk opened")

    def get_description(self):
        """Override parent method to add car-specific info"""
        base_desc = super().get_description()
        return f"{base_desc} ({self.num_doors}-door)"

class Motorcycle(Vehicle):
    """Motorcycle is another type of vehicle"""

    def __init__(self, make, model, year, engine_cc):
        super().__init__(make, model, year)
        self.engine_cc = engine_cc
        self.kickstand_down = True

    def wheelie(self):
        """Motorcycle-specific method"""
        if not self.kickstand_down:
            print("Performing a wheelie!")
        else:
            print("Can't wheelie with kickstand down")

    def get_description(self):
        """Override to add motorcycle-specific info"""
        base_desc = super().get_description()
        return f"{base_desc} ({self.engine_cc}cc)"

class ElectricCar(Car):
    """ElectricCar inherits from Car (multi-level inheritance)"""

    def __init__(self, make, model, year, num_doors, battery_capacity):
        super().__init__(make, model, year, num_doors)
        self.battery_capacity = battery_capacity  # kWh
        self.charge_level = 100  # percentage

    def charge(self, hours):
        """Electric-car-specific method"""
        charge_gained = min(hours * 10, 100 - self.charge_level)
        self.charge_level += charge_gained
        print(f"Charged for {hours} hours. Battery at {self.charge_level}%")

    def drive(self, distance):
        """Override to account for battery consumption"""
        battery_needed = distance * 0.3  # 0.3% per mile
        if battery_needed > self.charge_level:
            print("Insufficient battery charge!")
            return

        self.charge_level -= battery_needed
        super().drive(distance)  # Call parent's drive method
        print(f"Battery remaining: {self.charge_level:.1f}%")

    def get_description(self):
        """Override to add battery info"""
        base_desc = super().get_description()
        return f"{base_desc} (Electric, {self.battery_capacity}kWh battery)"

# Using the inheritance hierarchy
car = Car("Toyota", "Camry", 2022, 4)
motorcycle = Motorcycle("Harley-Davidson", "Street 750", 2023, 750)
ev = ElectricCar("Tesla", "Model 3", 2024, 4, 75)

# All vehicles can use base class methods
car.drive(50)
motorcycle.drive(30)
ev.drive(100)

# Each has its own specific methods
car.open_trunk()
motorcycle.wheelie()
ev.charge(2)

# Polymorphism - we'll explore this more next
vehicles = [car, motorcycle, ev]
for vehicle in vehicles:
    print(vehicle.get_description())

This example demonstrates several inheritance concepts:

Method Overriding: Subclasses can provide their own implementation of parent methods. ElectricCar overrides drive() to add battery management while still calling the parent’s drive() using super() [1].

The super() Function: super() provides access to the parent class’s methods. It’s essential for calling parent constructors and extending (rather than completely replacing) parent functionality [2].

Multi-level Inheritance: ElectricCar inherits from Car, which inherits from Vehicle, creating a three-level hierarchy. This models the relationship naturally: an electric car is a car, which is a vehicle [1].

Specialization: Each subclass adds specific attributes and methods relevant to its type. Car adds doors and trunk, Motorcycle adds engine displacement and wheelies, ElectricCar adds battery management [6].

When to Use Inheritance: Use inheritance when a genuine “is-a” relationship exists. An electric car IS-A car. A motorcycle IS-A vehicle. If the relationship feels forced, consider composition instead [6].

Polymorphism: Treating Related Objects Interchangeably#

Polymorphism (meaning “many forms”) enables treating objects of different classes through a common interface. The same method call produces different behavior depending on the object’s actual type. This is one of OOP’s most powerful features, enabling flexible, extensible code [2].

There are two main types of polymorphism:

1. Compile-time polymorphism (method overloading): Same method name with different parameters
2. Runtime polymorphism (method overriding): Subclasses provide different implementations of parent methods

Python doesn’t support method overloading in the traditional sense (though you can simulate it), but excels at runtime polymorphism through duck typing and inheritance [3].

Here’s a comprehensive example:

from abc import ABC, abstractmethod
import math

# Abstract base class defining the interface
class Shape(ABC):
    """Abstract shape class"""

    @abstractmethod
    def area(self):
        """Calculate area - must be implemented"""
        pass

    @abstractmethod
    def perimeter(self):
        """Calculate perimeter - must be implemented"""
        pass

    def describe(self):
        """Describe the shape - concrete method"""
        return f"{self.__class__.__name__}: area={self.area():.2f}, perimeter={self.perimeter():.2f}"

class Rectangle(Shape):
    """Rectangle implementation"""

    def __init__(self, width, height):
        self.width = width
        self.height = height

    def area(self):
        """Rectangle area calculation"""
        return self.width * self.height

    def perimeter(self):
        """Rectangle perimeter calculation"""
        return 2 * (self.width + self.height)

class Circle(Shape):
    """Circle implementation"""

    def __init__(self, radius):
        self.radius = radius

    def area(self):
        """Circle area calculation"""
        return math.pi * self.radius ** 2

    def perimeter(self):
        """Circle perimeter calculation"""
        return 2 * math.pi * self.radius

class Triangle(Shape):
    """Triangle implementation"""

    def __init__(self, side_a, side_b, side_c):
        self.side_a = side_a
        self.side_b = side_b
        self.side_c = side_c

    def area(self):
        """Triangle area using Heron's formula"""
        s = self.perimeter() / 2  # semi-perimeter
        return math.sqrt(s * (s - self.side_a) * (s - self.side_b) * (s - self.side_c))

    def perimeter(self):
        """Triangle perimeter calculation"""
        return self.side_a + self.side_b + self.side_c

# Polymorphism in action
def print_shape_info(shape: Shape):
    """Works with any Shape subclass - polymorphism!"""
    print(f"{shape.describe()}")

def calculate_total_area(shapes: list[Shape]) -> float:
    """Calculate total area of multiple shapes - polymorphism!"""
    return sum(shape.area() for shape in shapes)

def find_largest_shape(shapes: list[Shape]) -> Shape:
    """Find shape with largest area - polymorphism!"""
    return max(shapes, key=lambda shape: shape.area())

# Create different shape objects
rectangle = Rectangle(5, 3)
circle = Circle(4)
triangle = Triangle(3, 4, 5)

# Same function works with all shapes - polymorphism
print_shape_info(rectangle)  # Calls Rectangle's area/perimeter
print_shape_info(circle)     # Calls Circle's area/perimeter
print_shape_info(triangle)   # Calls Triangle's area/perimeter

# Treat different shapes uniformly
shapes = [rectangle, circle, triangle]

# Polymorphic behavior - each shape calculates area differently
total = calculate_total_area(shapes)
print(f"\nTotal area of all shapes: {total:.2f}")

largest = find_largest_shape(shapes)
print(f"Largest shape: {largest.describe()}")

# Duck typing - Python's approach to polymorphism
class Pentagon:
    """Pentagon - doesn't inherit from Shape but has required methods"""

    def __init__(self, side):
        self.side = side

    def area(self):
        """Pentagon area"""
        return (1/4) * math.sqrt(5 * (5 + 2 * math.sqrt(5))) * self.side ** 2

    def perimeter(self):
        """Pentagon perimeter"""
        return 5 * self.side

# Pentagon works with polymorphic functions even without inheritance!
pentagon = Pentagon(6)
print_shape_info(pentagon)  # Works! Duck typing in action

# Add to shapes list - works because it "quacks like a Shape"
shapes.append(pentagon)
print(f"Total area with pentagon: {calculate_total_area(shapes):.2f}")

This example showcases polymorphism’s power:

Common Interface: All shapes implement area() and perimeter() methods. Code that works with shapes doesn’t need to know each shape’s specific type—it just calls these methods [2].

Different Implementations: Each shape calculates area differently. Rectangle multiplies width by height, Circle uses πr², Triangle uses Heron’s formula. The caller doesn’t know or care about these details [3].

Type Substitution: calculate_total_area() accepts a list of shapes and works correctly regardless of which specific shape types it contains. You can add new shapes without modifying this function [4].

Duck Typing: Python’s approach to polymorphism is “if it walks like a duck and quacks like a duck, it’s a duck.” Pentagon doesn’t inherit from Shape but works with shape-processing functions because it has the required methods [3].

Extension Without Modification: Adding new shapes requires creating a new class, not modifying existing code. This exemplifies the Open/Closed Principle [5].

Composition vs. Inheritance: Choosing the Right Tool#

While inheritance models “is-a” relationships, composition models “has-a” relationships. Composition means building complex objects by combining simpler objects as components. This often provides more flexibility than inheritance [6].

The classic advice: “Favor composition over inheritance” doesn’t mean never use inheritance. It means don’t default to inheritance—consider whether composition might be more appropriate [6].

Here’s an example comparing the two approaches:

# Inheritance approach - can become problematic
class Employee:
    def __init__(self, name, salary):
        self.name = name
        self.salary = salary

class Manager(Employee):
    """Manager IS-AN Employee"""
    def __init__(self, name, salary, department):
        super().__init__(name, salary)
        self.department = department

class Developer(Employee):
    """Developer IS-AN Employee"""
    def __init__(self, name, salary, programming_language):
        super().__init__(name, salary)
        self.programming_language = programming_language

# What if someone is both a Manager AND a Developer?
# Inheritance struggles with multiple roles
# class ManagerDeveloper(Manager, Developer):  # Multiple inheritance - tricky!

# Composition approach - more flexible
class Role:
    """Represents a job role"""
    def __init__(self, title):
        self.title = title

    def get_description(self):
        return self.title

class ManagementRole(Role):
    """Management-specific role"""
    def __init__(self, department):
        super().__init__("Manager")
        self.department = department

    def get_description(self):
        return f"Manager of {self.department}"

class DevelopmentRole(Role):
    """Development-specific role"""
    def __init__(self, language):
        super().__init__("Developer")
        self.programming_language = language

    def get_description(self):
        return f"{self.programming_language} Developer"

class Employee:
    """Employee HAS roles (composition)"""
    def __init__(self, name, salary):
        self.name = name
        self.salary = salary
        self.roles = []  # Composition - employee HAS roles

    def add_role(self, role: Role):
        """Add a role to this employee"""
        self.roles.append(role)

    def get_description(self):
        """Describe employee's roles"""
        if not self.roles:
            return f"{self.name} - No assigned roles"

        role_desc = ", ".join(role.get_description() for role in self.roles)
        return f"{self.name} - {role_desc}"

# Composition allows multiple roles naturally
employee = Employee("Alex Johnson", 95000)
employee.add_role(ManagementRole("Engineering"))
employee.add_role(DevelopmentRole("Python"))

print(employee.get_description())
# Alex Johnson - Manager of Engineering, Python Developer

# Easy to add or remove roles dynamically
employee.roles.append(DevelopmentRole("JavaScript"))

When to Use Inheritance:

• Clear “is-a” relationship exists
• Subclass is a specialized version of the parent
• You want to leverage polymorphism through a common interface
• The hierarchy is relatively shallow (2-3 levels)

When to Use Composition:

• Relationship is “has-a” or “uses-a”
• You need multiple capabilities that don’t fit a single hierarchy
• Requirements may change dynamically
• You want to avoid fragile base class problems

The Fragile Base Class Problem: When parent class changes can unexpectedly break subclasses. Composition avoids this by depending on interfaces rather than implementation inheritance [6].

Common Pitfalls#

Pitfall 1: Breaking Encapsulation for Convenience

When under pressure, developers often bypass encapsulation by directly accessing or modifying private attributes. This creates tight coupling and makes refactoring dangerous.

# Bad - violates encapsulation
account.balance += 100  # Directly modifying internal state
account._transaction_history.append(...)  # Bypassing proper methods

# Good - use public interface
account.deposit(100)  # Proper encapsulation

Best Practice: Respect encapsulation boundaries even when it seems inconvenient. If you frequently need to bypass encapsulation, the class’s interface is probably incomplete—add proper methods rather than breaking encapsulation [2].

Pitfall 2: Inheritance Overuse and Deep Hierarchies

Creating deep inheritance hierarchies (4+ levels) makes code difficult to understand and modify. Changes high in the hierarchy affect all descendants, creating brittle code.

Best Practice: Keep hierarchies shallow (2-3 levels maximum). If you’re tempted to create deep hierarchies, consider composition or multiple smaller hierarchies. Use inheritance only for genuine “is-a” relationships [6].

Pitfall 3: Violating the Liskov Substitution Principle

Creating subclasses that can’t truly substitute for their parent breaks polymorphism and leads to runtime errors.

# Bad - violates LSP
class Bird:
    def fly(self):
        print("Flying")

class Penguin(Bird):
    def fly(self):
        raise Exception("Penguins can't fly!")  # Breaks contract

# Good - accurate hierarchy
class Bird:
    pass

class FlyingBird(Bird):
    def fly(self):
        print("Flying")

class Penguin(Bird):  # Not a FlyingBird
    def swim(self):
        print("Swimming")

Best Practice: Ensure subclasses can genuinely substitute for their parent. If you find yourself throwing exceptions or returning null in overridden methods, reconsider the inheritance hierarchy [5].

Pitfall 4: God Objects

Creating classes that do too much violates the Single Responsibility Principle and creates maintainability nightmares.

Best Practice: Each class should have a single, well-defined responsibility. If a class has more than 7-10 methods or requires “and” to describe its purpose, consider splitting it [5].

Summary#

Object-oriented programming provides a powerful paradigm for organizing code around objects that bundle data and behavior. The four pillars of OOP—encapsulation, abstraction, inheritance, and polymorphism—work together to create maintainable, extensible systems that model real-world concepts naturally.

Encapsulation bundles data with methods and restricts direct access to internal state, protecting object integrity and enabling implementation changes without affecting external code. Use properties and methods to provide controlled access, and respect access modifiers (private, protected, public).

Abstraction hides implementation complexity behind clear interfaces, allowing different implementations to be used interchangeably. Abstract classes and interfaces define contracts that concrete classes fulfill, enabling flexible system design.

Inheritance creates hierarchical relationships where subclasses inherit attributes and methods from parent classes. It enables code reuse and models “is-a” relationships, but should be used judiciously—deep hierarchies create maintenance problems.

Polymorphism allows treating objects of different classes through a common interface, with each object responding appropriately to the same method call. This enables writing flexible code that works with current and future classes without modification.

Composition vs. inheritance represents a crucial design choice. Use inheritance for genuine “is-a” relationships and polymorphism. Use composition for “has-a” relationships, dynamic capabilities, and to avoid fragile hierarchies. The advice “favor composition over inheritance” means consider both options thoughtfully, not that inheritance is always wrong.

Understanding and applying OOP principles effectively distinguishes professional software engineering from simple coding. These concepts underpin modern frameworks, design patterns, and architectural approaches. Mastering OOP enables you to create systems that are easier to understand, test, maintain, and extend as requirements evolve.

Practice Quiz#

Question 1: You’re designing a class to represent a shopping cart. Should total_price be stored as an attribute that’s updated whenever items are added/removed, or should it be calculated on-demand through a method? What principle guides this decision?

Answer: total_price should be calculated on-demand through a method (or property). This follows the Single Source of Truth principle and prevents data inconsistency. If you store total price as an attribute, it can become out of sync with the actual cart contents when items are added, removed, or have price changes.

class ShoppingCart:
    def __init__(self):
        self.items = []

    @property
    def total_price(self):
        """Calculate total dynamically"""
        return sum(item.price * item.quantity for item in self.items)

This approach ensures total_price is always accurate and consistent with the current cart state. It’s an example of proper encapsulation—the internal calculation is hidden, and external code accesses it through a clean interface [2][3].

Question 2: A Database class has methods for connecting, querying, and logging. A FileStorage class has methods for writing, reading, and logging. You notice both have identical logging code duplicated. How should you address this using OOP principles?

Answer: Extract the shared logging functionality into a separate class and use composition. Both Database and FileStorage can contain a Logger instance.

class Logger:
    """Reusable logging functionality"""
    def log(self, message, level="INFO"):
        timestamp = datetime.now().strftime("%Y-%m-%d %H:%M:%S")
        print(f"[{timestamp}] {level}: {message}")

class Database:
    def __init__(self):
        self.logger = Logger()  # Composition

    def query(self, sql):
        self.logger.log(f"Executing query: {sql}")
        # Query logic...

class FileStorage:
    def __init__(self):
        self.logger = Logger()  # Composition

    def write(self, data):
        self.logger.log(f"Writing {len(data)} bytes")
        # Write logic...

This follows DRY (Don’t Repeat Yourself) and demonstrates composition over inheritance. Both classes need logging but aren’t types of loggers, so composition is more appropriate than inheritance. It also follows the Single Responsibility Principle—each class has one clear purpose [5][6].

Question 3: You have a Shape abstract class with area() and perimeter() methods. You create a Square class that inherits from Shape. Should Square also inherit from a potential Rectangle class (since a square is a special rectangle)? Why or why not?

Answer: Be cautious about inheritance from Rectangle. While mathematically a square is a special rectangle, this can violate the Liskov Substitution Principle in code.

The problem arises if Rectangle has methods like:

class Rectangle(Shape):
    def set_width(self, width):
        self.width = width

    def set_height(self, height):
        self.height = height

A Square inheriting this behavior breaks LSP because a square’s width and height must always be equal. If code expects a Rectangle and calls set_width() and set_height() with different values, a Square can’t satisfy this contract without breaking its invariant.

Better approach: Have both inherit from Shape independently, or use composition where Square contains the logic for enforcing equal dimensions:

class Square(Shape):
    def __init__(self, side):
        self.side = side

    def area(self):
        return self.side ** 2

    def perimeter(self):
        return 4 * self.side

This avoids LSP violations and keeps the design clean. It’s a classic example where mathematical relationships don’t always translate directly to inheritance hierarchies [5].

Question 4: You’re building a payment system. You create an abstract PaymentMethod class and implement CreditCardPayment, PayPalPayment, and BitcoinPayment subclasses. Your CheckoutService accepts a PaymentMethod. What OOP principles make this design effective?

Answer: This design demonstrates abstraction, polymorphism, and the Dependency Inversion Principle.

Abstraction: PaymentMethod defines the interface (what methods exist) without specifying implementation (how they work). Each payment type provides its own implementation [4].

Polymorphism: CheckoutService can work with any PaymentMethod subclass interchangeably. The same code handles credit cards, PayPal, or Bitcoin without conditional logic checking the payment type [2].

Dependency Inversion Principle: CheckoutService depends on the abstract PaymentMethod interface, not concrete implementations. This means:

• You can add new payment methods without modifying CheckoutService
• Testing is easy—create a mock PaymentMethod for unit tests
• The high-level business logic (checkout) doesn’t depend on low-level details (specific payment APIs) [5]

This design is open for extension (add new payment methods) but closed for modification (don’t change existing code), exemplifying the Open/Closed Principle [5].

Question 5: Your User class has 15 methods including database operations, email sending, report generation, authentication, and validation. Code reviewers suggest this violates SOLID principles. Which principle is violated and how would you fix it?

Answer: This violates the Single Responsibility Principle (SRP). The User class has multiple reasons to change: database schema changes, email service changes, report format changes, authentication requirements changes, or validation rule changes [5].

Fix: Separate concerns into focused classes:

class User:
    """Represents user data only"""
    def __init__(self, username, email):
        self.username = username
        self.email = email

class UserRepository:
    """Handles database operations"""
    def save(self, user):
        # Database logic
        pass

    def find_by_id(self, user_id):
        # Database logic
        pass

class UserValidator:
    """Handles validation logic"""
    def validate(self, user):
        # Validation logic
        pass

class AuthenticationService:
    """Handles authentication"""
    def authenticate(self, username, password):
        # Auth logic
        pass

class EmailService:
    """Sends emails"""
    def send_welcome_email(self, user):
        # Email logic
        pass

class UserReportGenerator:
    """Generates reports"""
    def generate(self, users):
        # Report logic
        pass

Now each class has one reason to change. They’re easier to test (mock dependencies), easier to understand (clear purpose), and easier to modify (changes are isolated). This also enables better reusability—EmailService can send emails for any entity, not just users [5][6].

References#

[1] Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1994). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley. URL: https://www.pearson.com/en-us/subject-catalog/p/design-patterns-elements-of-reusable-object-oriented-software/P200000009451, Quote: “Object-oriented programming is a method of implementation in which programs are organized as cooperative collections of objects, each of which represents an instance of some class, and whose classes are all members of a hierarchy of classes united via inheritance relationships.”

[2] Martin, R. C. (2017). Clean Architecture: A Craftsman’s Guide to Software Structure and Design. Prentice Hall. URL: https://www.pearson.com/en-us/subject-catalog/p/clean-architecture-a-craftsmans-guide-to-software-structure-and-design/P200000009529, Quote: “Encapsulation is about bundling the data and the methods that operate on that data into a single unit, and restricting direct access to some of the object’s components. This is fundamental to protecting the integrity of the object’s state.”

[3] Lutz, M. (2013). Learning Python (5th Edition). O’Reilly Media. URL: https://www.oreilly.com/library/view/learning-python-5th/9781449355722/, Quote: “Python’s approach to polymorphism is duck typing: if an object walks like a duck and quacks like a duck, then it’s a duck. This means that polymorphism is achieved not through strict type hierarchies but through objects responding to the same method calls.”

[4] Bloch, J. (2018). Effective Java (3rd Edition). Addison-Wesley. URL: https://www.pearson.com/en-us/subject-catalog/p/effective-java/P200000009024, Quote: “Abstraction is the process of hiding implementation details and exposing only the essential features. Abstract classes and interfaces provide the mechanism for defining contracts that concrete classes must fulfill, enabling flexible and maintainable design.”

[5] Martin, R. C. (2008). Clean Code: A Handbook of Agile Software Craftsmanship. Prentice Hall. URL: https://www.pearson.com/en-us/subject-catalog/p/clean-code-a-handbook-of-agile-software-craftsmanship/P200000009044, Quote: “The SOLID principles are five principles of object-oriented design that work synergistically to create maintainable systems. The Single Responsibility Principle ensures each class has one reason to change; the Open/Closed Principle enables extension without modification; the Liskov Substitution Principle ensures subclasses can replace parents; the Interface Segregation Principle prevents interface bloat; and the Dependency Inversion Principle decouples high-level logic from low-level details.”

[6] Freeman, E., Robson, E., Sierra, K., & Bates, B. (2020). Head First Design Patterns (2nd Edition). O’Reilly Media. URL: https://www.oreilly.com/library/view/head-first-design/9781492077992/, Quote: “Favor composition over inheritance. Inheritance is a powerful tool but creates tight coupling between parent and child classes. Composition—building functionality by combining objects—often provides more flexibility and easier maintenance, especially when requirements change or when objects need capabilities from multiple sources.”