The Core Differences Between the Four Pillars of OOP

Mon, 13 Jul 2026 00:00:00 +0000

Mastering Object-Oriented Programming (OOP) requires more than just understanding its four pillars individually. To write clean and scalable systems, a developer must know how they differ, how they overlap, and how they work together.

In this article, we’ll break down the key differences between the pillars and compare them using simple code snippets in both Java and Python.

The Four Pillars at a Glance

Before comparing them, let’s look at the primary focus of each pillar:

Pillar	Core Question It Answers	Primary Objective
Encapsulation	How do I protect my data from unauthorized changes?	Data Hiding & Safety
Abstraction	What does this object do (without worrying about how it does it)?	Complexity Reduction
Inheritance	How can I reuse code from another class?	Code Reusability
Polymorphism	How can I implement a common interface in different ways?	Adaptability & Extensibility

1. Encapsulation vs. Abstraction: “How” vs. “What”

Developers often confuse Encapsulation and Abstraction because both involve hiding details. However, they operate at different levels of design:

Encapsulation (Data Hiding): Hides an object’s internal state (variables) and restricts direct access. It focuses on how data is managed and validated within a class.
Abstraction (Complexity Hiding): Hides the implementation details of a feature and exposes only a clean interface. It focuses on what the object does, hiding the underlying complexity from the caller.

Code Comparison

Python Example

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


# --- ABSTRACTION: Exposing a clean interface, hiding process complexity ---
from abc import ABC, abstractmethod

class Mailer(ABC):
 @abstractmethod
 def send_email(self, recipient: str, message: str):
 pass

class SendGridMailer(Mailer):
 def send_email(self, recipient: str, message: str):
 # Complex API negotiation, header formatting, and HTTP calls happen here
 print(f"Email sent via SendGrid to {recipient}")


# --- ENCAPSULATION: Hiding data variables and restricting direct access ---
class UserAccount:
 def __init__(self, username, email):
 self.username = username
 self.__email = email # Encapsulated (private) field

 def get_email(self):
 return self.__email

 def set_email(self, new_email):
 if "@" in new_email: # Validation check
 self.__email = new_email
 else:
 raise ValueError("Invalid email format")

Java Example

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36


// --- ABSTRACTION: Exposing a clean interface, hiding process complexity ---
interface Mailer {
 void sendEmail(String recipient, String message);
}

class SendGridMailer implements Mailer {
 @Override
 public void sendEmail(String recipient, String message) {
 // Complex API negotiation, header formatting, and HTTP calls happen here
 System.out.println("Email sent via SendGrid to " + recipient);
 }
}


// --- ENCAPSULATION: Hiding data variables and restricting direct access ---
class UserAccount {
 private String username;
 private String email; // Encapsulated (private) field

 public UserAccount(String username, String email) {
 this.username = username;
 this.email = email;
 }

 public String getEmail() {
 return this.email;
 }

 public void setEmail(String newEmail) {
 if (newEmail.contains("@")) { // Validation check
 this.email = newEmail;
 } else {
 throw new IllegalArgumentException("Invalid email format");
 }
 }
}

2. Inheritance vs. Polymorphism: “Structure” vs. “Behavior”

Inheritance and Polymorphism are closely linked, but they serve different engineering goals:

Inheritance (Structural Relationship): Establishes an “is-a” relationship between a base class (parent) and a derived class (child). It is design-time structure created to share code and attributes.
Polymorphism (Behavioral Flexibility): Translates to “many forms.” It allows subclasses to override inherited behaviors, letting the program choose the correct method implementation dynamically at runtime.

Code Comparison

Python Example

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


# --- INHERITANCE: Reusing brand & model fields ---
class Printer:
 def __init__(self, brand):
 self.brand = brand

 def print_document(self):
 print(f"Printing document from generic {self.brand} printer.")

class LaserPrinter(Printer): # Inherits brand field & printer structure
 pass


# --- POLYMORPHISM: Overriding method to exhibit customized behavior ---
class InkjetPrinter(Printer):
 def print_document(self): # Overrides parent method
 print(f"Spraying ink to print document from {self.brand} printer.")

# Polymorphism in action: Same interface, different outcomes
def process_print_job(printer: Printer):
 printer.print_document()

process_print_job(LaserPrinter("HP")) # Outputs: Printing document from generic HP printer.
process_print_job(InkjetPrinter("Canon")) # Outputs: Spraying ink to print document from Canon printer.

Java Example

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43


// --- INHERITANCE: Reusing brand field ---
class Printer {
 protected String brand;

 public Printer(String brand) {
 this.brand = brand;
 }

 public void printDocument() {
 System.out.println("Printing document from generic " + brand + " printer.");
 }
}

class LaserPrinter extends Printer { // Inherits brand field & printer structure
 public LaserPrinter(String brand) {
 super(brand);
 }
}


// --- POLYMORPHISM: Overriding method to exhibit customized behavior ---
class InkjetPrinter extends Printer {
 public InkjetPrinter(String brand) {
 super(brand);
 }

 @Override
 public void printDocument() { // Overrides parent method
 System.out.println("Spraying ink to print document from " + brand + " printer.");
 }
}

// Polymorphism in action: Same interface, different outcomes
public class Test {
 public static void processPrintJob(Printer printer) {
 printer.printDocument();
 }

 public static void main(String[] args) {
 processPrintJob(new LaserPrinter("HP")); // Outputs generic print behavior
 processPrintJob(new InkjetPrinter("Canon")); // Outputs overridden print behavior
 }
}

How They Work Together in Practice

The four pillars rarely work in isolation. In high-quality enterprise applications:

Abstraction defines the high-level system components and layout boundaries (e.g., an interface for database connections).
Inheritance lets you share general connection attributes across specific drivers (e.g., MySQL vs. PostgreSQL).
Polymorphism allows the application to switch drivers dynamically at runtime without modifying the caller code.
Encapsulation protects credentials and internal connection states (like socket descriptors and passwords) from external tampering.

Conclusion

Understanding the unique characteristics of each OOP pillar prevents architectural anti-patterns:

Use Encapsulation to protect and validate your object states.
Use Abstraction to clean up complicated APIs and expose only what is necessary.
Use Inheritance to reuse code, but be careful not to create tightly coupled nested structures (favor composition where appropriate).
Use Polymorphism to write flexible algorithms that adapt to new object types dynamically at runtime.

Comparison on Noman Chowdhury Munna | Blog

The Core Differences Between the Four Pillars of OOP

The Four Pillars at a Glance

1. Encapsulation vs. Abstraction: “How” vs. “What”

Code Comparison

Python Example

Java Example

2. Inheritance vs. Polymorphism: “Structure” vs. “Behavior”

Code Comparison

Python Example

Java Example

How They Work Together in Practice

Conclusion