Skip to content
Software Engineering Hub

The Four Pillars of OOP

Object-Oriented Programming (OOP) is a programming paradigm built on the concept of objects — entities that bundle data and the behavior that operates on that data. Four fundamental principles, often called the “Four Pillars,” form the foundation of effective OOP design. Understanding these pillars is essential for writing code that is organized, reusable, and maintainable.

1. Encapsulation

What Is Encapsulation?

Encapsulation is the practice of bundling data (attributes) and the methods that operate on that data into a single unit (a class), while restricting direct access to some of the object’s internals. Rather than exposing raw data fields for anyone to read and write, an encapsulated class provides controlled access through well-defined methods.

The two key ideas are:

  1. Data hiding — internal state is kept private or protected, shielded from outside interference.
  2. Controlled access — public methods (getters, setters, or domain-specific operations) serve as the only gateway to internal state.

Real-World Analogy

Think of an ATM machine. You interact with it through a screen and keypad (the public interface), but you never touch the cash vault, the transaction processor, or the network connection directly. The ATM encapsulates all of that complexity and only exposes the operations you need: check balance, withdraw cash, deposit funds. If the bank changes how transactions are processed internally, your experience at the ATM stays the same.

Code Examples

class BankAccount:
    """Encapsulates account data and provides controlled access."""


    def __init__(self, owner: str, initial_balance: float = 0.0):
        self._owner = owner            # Protected attribute
        self.__balance = initial_balance  # Private attribute (name-mangled)
        self.__transaction_log: list[str] = []


    @property
    def owner(self) -> str:
        """Read-only access to the owner name."""
        return self._owner


    @property
    def balance(self) -> float:
        """Read-only access to the current balance."""
        return self.__balance


    def deposit(self, amount: float) -> None:
        """Controlled method to add funds."""
        if amount <= 0:
            raise ValueError("Deposit amount must be positive")
        self.__balance += amount
        self.__log(f"Deposited ${amount:.2f}")


    def withdraw(self, amount: float) -> None:
        """Controlled method to remove funds with validation."""
        if amount <= 0:
            raise ValueError("Withdrawal amount must be positive")
        if amount > self.__balance:
            raise ValueError("Insufficient funds")
        self.__balance -= amount
        self.__log(f"Withdrew ${amount:.2f}")


    def get_statement(self) -> list[str]:
        """Returns a copy of the transaction log."""
        return self.__transaction_log.copy()


    def __log(self, message: str) -> None:
        """Private helper -- not accessible from outside."""
        self.__transaction_log.append(message)




# Usage
account = BankAccount("Alice", 1000.0)
account.deposit(500.0)
account.withdraw(200.0)


print(account.owner)     # "Alice"
print(account.balance)   # 1300.0
print(account.get_statement())
# ["Deposited $500.00", "Withdrew $200.00"]


# Direct access to __balance is prevented:
# account.__balance  --> AttributeError

Benefits of Encapsulation

  • Data integrity — validation logic in setters prevents objects from entering an invalid state.
  • Reduced coupling — external code depends on the public interface, not the internal representation. You can change how data is stored without affecting callers.
  • Easier debugging — when a value changes unexpectedly, you only need to look at the methods that can modify it, not the entire codebase.
  • Controlled side effects — operations like logging, event notification, and validation happen automatically through methods.

2. Abstraction

What Is Abstraction?

Abstraction is the principle of exposing only the essential features of an object while hiding the unnecessary implementation details. Where encapsulation is about how you protect data, abstraction is about what you choose to expose. A well-abstracted class presents a simple, focused interface that lets users accomplish their goals without needing to understand the complexity underneath.

Abstraction is typically achieved through:

  1. Abstract classes — classes that cannot be instantiated directly and that define a contract (method signatures) for subclasses.
  2. Interfaces — pure contracts with no implementation (in languages that support them).

Real-World Analogy

Consider driving a car. The steering wheel, pedals, and gear shift form a simple, abstract interface. You do not need to understand fuel injection timing, valve lift profiles, or ABS sensor calibration to drive. The car abstracts away thousands of mechanical and electronic details behind a manageable set of controls. Different car models may use entirely different engine technologies, but the driver’s interface remains largely the same.

Code Examples

from abc import ABC, abstractmethod




class PaymentProcessor(ABC):
    """Abstract class defining the payment interface.
    Hides implementation details behind a clean contract."""


    @abstractmethod
    def authorize(self, amount: float) -> bool:
        """Verify the payment can be processed."""
        pass


    @abstractmethod
    def capture(self, amount: float) -> str:
        """Execute the actual payment."""
        pass


    @abstractmethod
    def refund(self, transaction_id: str, amount: float) -> bool:
        """Reverse a completed payment."""
        pass


    def process_payment(self, amount: float) -> str:
        """Template method -- users call this, not the details."""
        if not self.authorize(amount):
            raise ValueError("Payment authorization failed")
        transaction_id = self.capture(amount)
        return transaction_id




class CreditCardProcessor(PaymentProcessor):
    """Hides the complexity of credit card networks."""


    def __init__(self, card_number: str, expiry: str):
        self._card = card_number
        self._expiry = expiry


    def authorize(self, amount: float) -> bool:
        # In reality: contact card network, verify funds, check fraud
        print(f"Authorizing ${amount:.2f} on card ***{self._card[-4:]}")
        return True


    def capture(self, amount: float) -> str:
        # In reality: submit to payment gateway, handle 3D-Secure
        print(f"Captured ${amount:.2f}")
        return f"CC-TXN-{id(self)}"


    def refund(self, transaction_id: str, amount: float) -> bool:
        print(f"Refunded ${amount:.2f} for {transaction_id}")
        return True




class PayPalProcessor(PaymentProcessor):
    """Hides the complexity of PayPal's API."""


    def __init__(self, email: str):
        self._email = email


    def authorize(self, amount: float) -> bool:
        print(f"Authorizing ${amount:.2f} via PayPal ({self._email})")
        return True


    def capture(self, amount: float) -> str:
        print(f"Captured ${amount:.2f} via PayPal")
        return f"PP-TXN-{id(self)}"


    def refund(self, transaction_id: str, amount: float) -> bool:
        print(f"Refunded ${amount:.2f} via PayPal for {transaction_id}")
        return True




# Client code works with the abstraction, not the details
def checkout(processor: PaymentProcessor, amount: float) -> str:
    return processor.process_payment(amount)




# Usage -- the checkout function doesn't know or care
# whether it's a credit card or PayPal under the hood
cc = CreditCardProcessor("4111111111111111", "12/26")
txn = checkout(cc, 49.99)


pp = PayPalProcessor("user@example.com")
txn = checkout(pp, 29.99)

Benefits of Abstraction

  • Reduced complexity — users interact with a simple interface without worrying about internal mechanics.
  • Interchangeability — different implementations can be swapped without changing client code.
  • Focus on “what,” not “how” — consumers of your class think in terms of domain operations, not implementation details.
  • Parallel development — teams can work against an abstract interface while concrete implementations are developed independently.

3. Inheritance

What Is Inheritance?

Inheritance is a mechanism that allows a new class (the child or subclass) to acquire the properties and behaviors of an existing class (the parent or superclass). The child class inherits the fields and methods of the parent and can add new ones or override existing ones to specialize behavior.

Inheritance models an “is-a” relationship. A Dog is an Animal. A SavingsAccount is a BankAccount. If the relationship does not naturally read as “is-a,” inheritance is likely the wrong tool.

Real-World Analogy

Think of biological taxonomy. All mammals share certain traits: they are warm-blooded, they have hair, they nurse their young. Dogs, cats, and whales are all mammals, so they inherit these traits. But each species also has specialized characteristics: dogs bark, cats purr, whales have blowholes. The species inherit the general mammal traits while adding or overriding specific behaviors of their own.

Code Examples

class Vehicle:
    """Base class representing a generic vehicle."""


    def __init__(self, make: str, model: str, year: int):
        self.make = make
        self.model = model
        self.year = year
        self._speed = 0.0


    def accelerate(self, amount: float) -> None:
        self._speed += amount
        print(f"{self} accelerated to {self._speed:.1f} mph")


    def brake(self, amount: float) -> None:
        self._speed = max(0, self._speed - amount)
        print(f"{self} slowed to {self._speed:.1f} mph")


    def __str__(self) -> str:
        return f"{self.year} {self.make} {self.model}"




class ElectricCar(Vehicle):
    """Inherits from Vehicle and adds battery-specific features."""


    def __init__(self, make: str, model: str, year: int, battery_kwh: float):
        super().__init__(make, model, year)  # Call parent constructor
        self.battery_kwh = battery_kwh
        self.charge_level = 100.0  # percentage


    def charge(self, amount: float) -> None:
        """New method specific to electric cars."""
        self.charge_level = min(100.0, self.charge_level + amount)
        print(f"{self} charged to {self.charge_level:.1f}%")


    def accelerate(self, amount: float) -> None:
        """Override parent method to consume battery."""
        if self.charge_level <= 0:
            print(f"{self} has no charge!")
            return
        self.charge_level -= amount * 0.1
        super().accelerate(amount)  # Reuse parent logic




class Truck(Vehicle):
    """Inherits from Vehicle and adds cargo-specific features."""


    def __init__(self, make: str, model: str, year: int, payload_tons: float):
        super().__init__(make, model, year)
        self.payload_tons = payload_tons
        self.cargo_weight = 0.0


    def load_cargo(self, weight: float) -> None:
        if self.cargo_weight + weight > self.payload_tons:
            raise ValueError("Exceeds payload capacity!")
        self.cargo_weight += weight
        print(f"{self} loaded {weight:.1f}t (total: {self.cargo_weight:.1f}t)")


    def accelerate(self, amount: float) -> None:
        """Override: heavier cargo means slower acceleration."""
        load_factor = 1 - (self.cargo_weight / self.payload_tons) * 0.5
        adjusted = amount * load_factor
        super().accelerate(adjusted)




# Usage
tesla = ElectricCar("Tesla", "Model 3", 2024, 75.0)
tesla.accelerate(30)   # Inherited + overridden behavior
tesla.charge(10)       # ElectricCar-specific method


truck = Truck("Ford", "F-150", 2024, 1.5)
truck.load_cargo(0.8)  # Truck-specific method
truck.accelerate(20)   # Adjusted for cargo weight


# Inheritance check
print(isinstance(tesla, Vehicle))  # True -- ElectricCar IS-A Vehicle
print(isinstance(truck, Vehicle))  # True -- Truck IS-A Vehicle

Benefits of Inheritance

  • Code reuse — common functionality lives in the parent class and is automatically available to all children.
  • Hierarchical organization — models natural “is-a” relationships, making code easier to reason about.
  • Extensibility — new subclasses can be added without modifying existing parent code.
  • Method overriding — subclasses can customize inherited behavior while still reusing parent logic through super().

When to Use (and When Not To)

Use inheritance when:

  • There is a clear, natural “is-a” relationship.
  • Subclasses genuinely share behavior and you want to avoid duplicating it.
  • You need polymorphic behavior (treating different types through a common interface).

Avoid inheritance when:

  • The relationship is better described as “has-a” (use composition instead).
  • You find yourself inheriting just to reuse a small piece of code.
  • The class hierarchy becomes deeper than 2-3 levels — deep hierarchies are fragile and hard to change.

4. Polymorphism

What Is Polymorphism?

Polymorphism (from Greek: “many forms”) is the ability of different objects to respond to the same method call in their own way. When you call a method on an object, the actual behavior that executes depends on the object’s type, not the variable’s declared type. This lets you write code that works with a general type while automatically adapting to the specific type at runtime.

There are two main forms:

  1. Runtime (subtype) polymorphism — achieved through method overriding. The most common form in OOP. A parent type reference can point to any child type, and the correct overridden method is called at runtime.
  2. Compile-time (ad-hoc) polymorphism — achieved through method overloading (same method name, different parameter signatures) or operator overloading. Available in languages like Java and C++.

Real-World Analogy

Consider a universal remote control. The “power” button sends the same signal concept to any device — a TV, a sound system, a streaming box. Each device responds to the same command differently: the TV displays a picture, the sound system starts playing audio, the streaming box boots its interface. The remote does not need to know the internal workings of each device. It simply sends a unified command, and each device interprets it in its own way. That is polymorphism.

Code Examples

from abc import ABC, abstractmethod
import math




class Shape(ABC):
    """Base class for all shapes."""


    @abstractmethod
    def area(self) -> float:
        pass


    @abstractmethod
    def perimeter(self) -> float:
        pass


    def describe(self) -> str:
        """Same method works for any shape -- polymorphism in action."""
        return (
            f"{self.__class__.__name__}: "
            f"area={self.area():.2f}, perimeter={self.perimeter():.2f}"
        )




class Circle(Shape):
    def __init__(self, radius: float):
        self.radius = radius


    def area(self) -> float:
        return math.pi * self.radius ** 2


    def perimeter(self) -> float:
        return 2 * math.pi * self.radius




class Rectangle(Shape):
    def __init__(self, width: float, height: float):
        self.width = width
        self.height = height


    def area(self) -> float:
        return self.width * self.height


    def perimeter(self) -> float:
        return 2 * (self.width + self.height)




class Triangle(Shape):
    def __init__(self, a: float, b: float, c: float):
        self.a = a
        self.b = b
        self.c = c


    def area(self) -> float:
        # Heron's formula
        s = self.perimeter() / 2
        return math.sqrt(s * (s - self.a) * (s - self.b) * (s - self.c))


    def perimeter(self) -> float:
        return self.a + self.b + self.c




# Polymorphism in action: one function handles ALL shapes
def print_shape_report(shapes: list[Shape]) -> None:
    total_area = 0.0
    for shape in shapes:
        print(shape.describe())  # Each shape responds differently
        total_area += shape.area()
    print(f"Total area: {total_area:.2f}")




# Usage
shapes: list[Shape] = [
    Circle(5),
    Rectangle(4, 6),
    Triangle(3, 4, 5),
]


print_shape_report(shapes)
# Circle: area=78.54, perimeter=31.42
# Rectangle: area=24.00, perimeter=20.00
# Triangle: area=6.00, perimeter=12.00
# Total area: 108.54

Benefits of Polymorphism

  • Extensibility — new types can be added without changing existing code that uses the base type.
  • Cleaner code — eliminates long if/else or switch chains that check object types.
  • Flexibility — algorithms can work with abstract types and automatically handle any concrete implementation.
  • Testability — mock objects can implement the same interface for unit testing.

Comparison of the Four Pillars

PillarCore IdeaKey MechanismPrimary Benefit
EncapsulationBundle data + methods; hide internalsAccess modifiers (private, protected, public)Data integrity and reduced coupling
AbstractionExpose what, hide howAbstract classes and interfacesSimplicity and interchangeability
InheritanceChild classes acquire parent behaviorextends / : (subclassing)Code reuse and hierarchical modeling
PolymorphismSame interface, different behaviorMethod overriding and virtual dispatchExtensibility and flexibility

How They Work Together

The four pillars are not independent — they reinforce each other:

  1. Encapsulation protects the internal state that Abstraction hides from the user.
  2. Inheritance provides the class hierarchy through which Polymorphism operates.
  3. Abstraction defines the contract that Polymorphism leverages — subclasses provide different implementations of the same abstract methods.
  4. Encapsulation in a parent class means child classes that Inherit its fields interact with them through controlled methods rather than directly.

Key Takeaways

  1. Encapsulation is your first line of defense against bugs. By controlling how data is accessed and modified, you prevent objects from reaching invalid states and make your code easier to debug and maintain.

  2. Abstraction is about managing complexity. Well-designed abstractions let you think at a higher level and swap implementations without rewriting client code. Focus on what an object does, not how it does it.

  3. Inheritance is powerful but should be used judiciously. Prefer shallow hierarchies (2-3 levels deep). If you are inheriting only to reuse code, composition is usually a better choice. Always verify the “is-a” relationship makes logical sense.

  4. Polymorphism is the payoff. Once you have good abstractions and a clean class hierarchy, polymorphism lets you write general-purpose code that handles any number of specific types — present and future — without modification.

  5. The pillars work together. Encapsulation without abstraction leads to cluttered interfaces. Inheritance without polymorphism is just code sharing. The real power emerges when all four principles are applied in concert.

Practice Exercises

Exercise 1: Media Player System

Design a media player system using all four pillars:

  • Create a base MediaPlayer class with encapsulated state (current track, volume, playing status).
  • Define an abstract method decode(file_path) that different player subclasses implement (MP3Player, WAVPlayer, FLACPlayer).
  • Write a Playlist class that holds a list of MediaPlayer references and can call play() on each one polymorphically.

Stretch goal: Add a StreamingPlayer subclass that overrides the decode method to stream from a URL instead of reading a file.

Exercise 2: Zoo Management

Model a zoo with inheritance and polymorphism:

  • Create a base Animal class with encapsulated attributes (name, species, age, hunger_level).
  • Add subclasses: Mammal, Bird, Reptile, each with a make_sound() method that returns a different string.
  • Write a Zookeeper class with a feed_all(animals) method that iterates through a list of Animal objects and calls feed() on each one, demonstrating polymorphism.
  • Use abstraction to define a Feedable interface that both animals and hypothetical Plant objects could implement.

Exercise 3: Plugin Architecture

Build a plugin system that demonstrates abstraction and polymorphism:

  • Define an abstract Plugin class with methods: initialize(), execute(data), shutdown().
  • Implement at least three concrete plugins: LoggingPlugin, ValidationPlugin, TransformPlugin.
  • Create a PluginManager class that loads plugins, calls initialize() on all of them, and routes data through each plugin’s execute() method in sequence.
  • Encapsulate the plugin list inside PluginManager so that external code cannot modify it directly.

Next Steps

SOLID Principles Learn the five principles that guide clean, maintainable object-oriented design
Composition vs Inheritance Understand when to use 'has-a' relationships instead of 'is-a' hierarchies