How to Implement Composition in Object Oriented Programming

Understanding the Has-A Relationship in Object Design

In the architecture of robust software, the most dangerous question a developer can ask is, "What is this class?" The better question is, "What does this class contain?"

This shift in perspective moves you from the rigid trap of Inheritance (Is-A) to the flexible power of Composition (Has-A). When you design a system where objects are built by assembling smaller, specialized components, you create software that is resilient, testable, and infinitely adaptable.

Think of a House. It is not a "super-room." It has rooms. It has a foundation. It has a roof. If you inherit from a Room to make a House, you end up with a structure that is too small to live in. Instead, you compose the House from its parts.

The Mechanics of Composition

Composition allows you to swap out behaviors at runtime. If your House needs a new kitchen, you don't rewrite the House class. You simply replace the Kitchen object inside it. This decoupling is the secret sauce of scalable systems.

For a deeper dive into why this pattern often beats inheritance, check out our guide on composition over inheritance practical.

Implementation in Code

Let's look at how this translates to Python. Notice how the Car class doesn't inherit from Engine. It simply owns an engine. This is the essence of the composition vs inheritance making right philosophy.

# The Component (Engine) class Engine: def __init__(self, horsepower): self.horsepower = horsepower def start(self): return f"Vroom! {self.horsepower} HP engine roaring." # The Composite (Car) class Car: def __init__(self, model, horsepower): # HAS-A relationship: Car contains an Engine self.model = model self.engine = Engine(horsepower) def drive(self): # Delegation: Car asks Engine to do the work status = self.engine.start() return f"{self.model} is moving. {status}" # Usage my_sports_car = Car("Porsche 911", 450) print(my_sports_car.drive()) # Output: Porsche 911 is moving. Vroom! 450 HP engine roaring.

Key Takeaways

• Prefer "Has-A" over "Is-A": Use composition to build systems from parts rather than extending base classes.
• Runtime Flexibility: Composition allows you to change behavior while the program is running, not just at compile time.
• Testability: Small, composed components are easier to unit test in isolation than a massive inherited class.

Composition vs Inheritance: Choosing the Right Design Strategy

As a Senior Architect, I often see junior developers reach for Inheritance like a hammer, treating every problem as a nail. While inheritance models an "Is-A" relationship, it creates rigid, fragile structures. Composition, on the other hand, models a "Has-A" relationship, offering the flexibility to assemble systems from interchangeable parts.

 class Set: def __init__(self): self._items = [] def add(self, item): self._items.append(item) def size(self): return len(self._items) # The Trap: Inheriting behavior class CountingSet(Set): def __init__(self): super().__init__() self._count = 0 def add(self, item): # If parent 'add' calls 'add' internally (e.g. for validation), # our counter increments TWICE! super().add(item) self._count += 1 

 class CountingSet: def __init__(self): # We own the implementation details self._items = [] self._count = 0 def add(self, item): # Explicit control over logic if item not in self._items: self._items.append(item) self._count += 1 def size(self): return self._count 

Key Takeaways

• Prefer "Has-A" over "Is-A": Use composition to build systems from parts rather than extending base classes. This reduces coupling significantly.
• Runtime Flexibility: Composition allows you to change behavior while the program is running, not just at compile time.
• Testability: Small, composed components are easier to unit test in isolation than a massive inherited class.
• Further Reading: For a deeper dive into this specific pattern, check out our guide on composition over inheritance practical.

Implementing Composition in Python: A Step-by-Step Guide

Welcome to the workshop floor. Today, we aren't just writing code; we are architecting systems. In the world of professional software engineering, Composition is the art of building complex systems by assembling smaller, specialized components. It is the antidote to the rigid, fragile nature of deep inheritance hierarchies.

Think of a car. It doesn't inherit from an Engine. It has an Engine. It has Brakes. It has a Steering Wheel. By treating these as distinct objects passed into the Car, we achieve a level of flexibility that inheritance simply cannot match. If you want to swap a V8 engine for an Electric motor, you don't rewrite the Car class; you just swap the component.

The Blueprint: Dependency Injection

The mechanism that makes composition work is Dependency Injection. Instead of a class creating its own dependencies (tight coupling), we inject them from the outside. This makes your code modular, testable, and robust.

# 1. Define the Components (The "Parts") class Engine: def __init__(self, type_): self.type = type_ def start(self): return f"{self.type} engine roaring to life." class BrakeSystem: def __init__(self, type_): self.type = type_ def apply(self): return f"{self.type} brakes engaging." # 2. Define the Composite (The "Whole") class Car: def __init__(self, engine, brakes): # Dependency Injection: We receive the parts, we don't create them self.engine = engine self.brakes = brakes def drive(self): # Delegate behavior to the components print(self.engine.start()) return "Car is moving." def stop(self): print(self.brakes.apply()) return "Car has stopped." # 3. Assembly (The "Factory" Logic) # We can mix and match parts dynamically v8_engine = Engine("V8 Petrol") disc_brakes = BrakeSystem("Ceramic Disc") my_car = Car(v8_engine, disc_brakes) print(my_car.drive()) print(my_car.stop()) 

Why This Matters for Scalability

When you rely on inheritance, you often end up with a "God Class" that tries to do everything. Composition allows you to break functionality into Single Responsibility units. This is critical when you are building concurrent applications or handling complex state management.

Mastering this pattern is essential for modern architecture. If you are struggling with the theoretical differences, I highly recommend reading composition over inheritance practical to see real-world scenarios where inheritance fails and composition saves the day.

OOP Composition Example: Constructing a Vehicle from Parts

As a Senior Architect, I often see junior developers try to model the world using deep, tangled inheritance trees. They ask, "Is a Car a Vehicle? Yes. Is a SportsCar a Car? Yes." But then they hit a wall: "Is a Car an Engine?" No. A Car has an Engine. This is the fundamental shift from "Is-A" to "Has-A".

In this masterclass, we aren't just defining classes; we are assembling a system. We will build a Vehicle by composing distinct, reusable components: an Engine, a set of Wheels, and a Chassis. This approach creates systems that are easier to test, maintain, and scale.

# 1. Define the Components (The Parts) class Engine: def __init__(self, horsepower): self.horsepower = horsepower def start(self): return f"Vroom! {self.horsepower} HP engine ignited." class Wheel: def __init__(self, size): self.size = size def rotate(self): return f"Wheel {self.size} inch rotating." # 2. Define the Composite Object (The Whole) class Vehicle: def __init__(self, engine_hp, wheel_size): # Composition: The Vehicle 'has-a' Engine and 'has-a' Wheel self.engine = Engine(engine_hp) self.wheels = [Wheel(wheel_size) for _ in range(4)] def drive(self): # Delegate responsibility to components print(self.engine.start()) for wheel in self.wheels: print(wheel.rotate()) # 3. Usage my_car = Vehicle(300, 18) my_car.drive()

Composition Over Inheritance: Why Flexibility Wins

In the early days of Object-Oriented Programming (OOP), inheritance was the golden hammer. If you needed a new type of object, you simply extended an existing one. But as systems grew, we hit the "Brittle Base Class" problem. A change in the parent class could silently break a dozen subclasses.

Today, we embrace a more robust philosophy: Composition over Inheritance. Instead of defining what an object is (Is-A relationship), we define what an object has (Has-A relationship). This approach decouples your system, making it modular, testable, and resilient to change.

# ❌ INHERITANCE: Tightly Coupled
class Bird:
    def fly(self):
        return "Flying with wings"

class Penguin(Bird):
    # ERROR: Penguins cannot fly!
    # We are forced to override or break the contract.
    def fly(self):
        raise Exception("Penguins cannot fly")

# ✅ COMPOSITION: Flexible & Modular
class Flyable:
    def fly(self):
        return "Flying with wings"

class Swimmable:
    def swim(self):
        return "Swimming with flippers"

class Penguin:
    def __init__(self):
        # Composition allows us to pick only what we need
        self.swimmer = Swimmable()

    def swim(self):
        return self.swimmer.swim()

Advanced Object Composition: Strategy and Decorator Patterns

Welcome to the next level of architectural design. Up until now, you've likely relied heavily on inheritance to build your systems. While inheritance is powerful, it creates rigid hierarchies that are difficult to maintain as your application grows. Today, we shift our paradigm to Composition. We will explore two of the most potent design patterns in the Gang of Four (GoF) catalog: the Strategy Pattern for swapping algorithms at runtime, and the Decorator Pattern for adding responsibilities dynamically without subclassing.

1. The Strategy Pattern: Swapping Algorithms at Runtime

Imagine you are building a payment processing system. You have Credit Cards, PayPal, and Bitcoin. If you use inheritance, you might create a `PaymentProcessor` class and extend it for each type. But what if you want to switch payment methods dynamically based on user preference or transaction amount? That is where the Strategy Pattern shines. It defines a family of algorithms, encapsulates each one, and makes them interchangeable.

The diagram above illustrates the power of indirection. The Context doesn't care how the work is done, only that it is done. This decoupling is essential for scalable systems.

# Strategy Interface class PaymentStrategy: def pay(self, amount): pass # Concrete Strategies class CreditCardPayment(PaymentStrategy): def __init__(self, card_number): self.card_number = card_number def pay(self, amount): print(f"Paying ${amount} using Credit Card ending in {self.card_number[<-4:]}") class CryptoPayment(PaymentStrategy): def __init__(self, wallet_address): self.wallet_address = wallet_address def pay(self, amount): print(f"Paying ${amount} using Crypto from {self.wallet_address[<:8]}...") # Context class ShoppingCart: def __init__(self): self.items = [] self.payment_strategy = None def set_payment(self, strategy): self.payment_strategy = strategy def checkout(self): total = sum(self.items) if self.payment_strategy: self.payment_strategy.pay(total) else: print("No payment method selected.") # Usage cart = ShoppingCart() cart.items = [100, 50, 25] # Client decides strategy at runtime cart.set_payment(CreditCardPayment("1234-5678-9012-3456")) cart.checkout() # Switch strategy dynamically cart.set_payment(CryptoPayment("0x71C7656EC7ab88b098defB751B7401B5f6d8976F")) cart.checkout()

2. The Decorator Pattern: The "Russian Doll" Architecture

Sometimes, you need to add functionality to an object without modifying its code. Inheritance forces you to create a new subclass for every combination of features (e.g., CompressedEncryptedFile, EncryptedCompressedFile). This leads to class explosion. The Decorator Pattern solves this by wrapping the original object with new behavior, layer by layer.

Notice how CompressionDecorator and EncryptionDecorator both implement the DataSource interface. This allows you to stack them: new EncryptionDecorator(new CompressionDecorator(new FileDataSource())). This concept is similar to how RAII manages resources in C++, ensuring cleanup happens in reverse order of construction.

import base64 import zlib class DataSource: def write_data(self, data): pass def read_data(self): pass class FileDataSource(DataSource): def __init__(self, filename): self.filename = filename self.data = "" def write_data(self, data): self.data = data print(f"Writing raw data to {self.filename}") def read_data(self): return self.data # The Decorator Base class DataSourceDecorator(DataSource): def __init__(self, source): self.source = source def write_data(self, data): self.source.write_data(data) def read_data(self): return self.source.read_data() # Concrete Decorators class CompressionDecorator(DataSourceDecorator): def write_data(self, data): compressed = zlib.compress(data.encode()) print("Compressing data...") super().write_data(compressed) def read_data(self): compressed = super().read_data() if isinstance(compressed, bytes): return zlib.decompress(compressed).decode() return compressed class EncryptionDecorator(DataSourceDecorator): def write_data(self, data): # Simple Base64 encoding for demo (not real encryption) encoded = base64.b64encode(data.encode()).decode() print("Encrypting data...") super().write_data(encoded) def read_data(self): encoded = super().read_data() if isinstance(encoded, str): return base64.b64decode(encoded).decode() return encoded # Usage: Stacking Decorators source = FileDataSource("report.txt") source = CompressionDecorator(source) source = EncryptionDecorator(source) source.write_data("Secret Data") print(f"Read back: {source.read_data()}")

Key Takeaways for the Senior Architect

Best Practices and Common Pitfalls in OOP Design

Welcome to the architecture layer. You have learned the syntax of classes and objects, but now we must address the art of design. Writing code that compiles is easy; writing code that scales, survives refactoring, and remains readable is the mark of a true Senior Engineer.

Object-Oriented Programming (OOP) is a double-edged sword. Used correctly, it creates modular, robust systems. Used poorly, it creates "spaghetti code" wrapped in class definitions. In this masterclass, we will dissect the most common architectural anti-patterns and replace them with industry-standard best practices.

The Interactive Anti-Pattern Checklist

Before you write your next class, run it through this mental model. These are the most common reasons systems fail in production.

Code Review: Refactoring for Safety

Let's look at a concrete example. We will refactor a class that violates the RAII (Resource Acquisition Is Initialization) principle by leaking file handles.

 class DataProcessor: def __init__(self, filename): self.filename = filename # Resource acquired but not managed self.file = open(filename, 'r') def process(self): data = self.file.read() # What if an error happens here? # The file handle stays open! return data.upper() # User must remember to call this manually def close(self): self.file.close() 

 class DataProcessor: def __init__(self, filename): self.filename = filename # Context Manager Protocol (Python's version of RAII) def __enter__(self): self.file = open(self.filename, 'r') return self def __exit__(self, exc_type, exc_val, exc_tb): # Guaranteed cleanup even on error if self.file: self.file.close() def process(self): with self.file as f: return f.read().upper() # Usage: # File is automatically closed after the block with DataProcessor('data.txt') as processor: result = processor.process()