OBJECT-ORIENTED PROGRAMMING
(OOPs)
ARCHITECTURE AND PRINCIPLES
A Technical Reference Manual on Classes, Objects, and the Core Pillars of
OOPs
Subject: Software Engineering & Object-Oriented Paradigm
Version: 1.0
Status: Core Technical Study Guide
1. Introduction to the Object-Oriented
Paradigm
Object-Oriented Programming (OOPs) is a fundamental programming paradigm based
on the concept of 'objects', which can contain data in the form of fields (often known as
attributes or properties) and code in the form of procedures (often known as methods).
OOPs shifts the software design focus from purely procedural execution pipelines to
modeling self-contained modular components.
1.1 Classes vs. Objects
Understanding the precise relationship between a Class and an Object is essential for
object-oriented engineering:
Class: A class is a blueprint, prototype, or abstract data type definition that
describes the attributes and behaviors common to all objects of that type. It
occupies no physical memory space during runtime execution.
Object: An object is a concrete instance of a class. When an object is instantiated,
memory is allocated on the system heap to store its specific attribute state values.
2. The Four Pillars of OOPs
The structural integrity and modularity of any object-oriented application depend
entirely on four foundational architectural pillars.
2.1 Encapsulation
Encapsulation refers to the bundling of data attributes and the methods that operate on
that data into a singular physical class boundary. Concurrently, it restricts direct
external access to some of the object's internal components, a concept known as data
hiding.
This is strictly achieved using access modifiers (e.g., private, protected, public). External
objects must interact with data attributes via safe, validated public access methods
called getters and setters.
2.2 Abstraction
Abstraction is the process of hiding complex internal implementation details while
displaying only essential operational interfaces to the outside world. It helps reduce
cognitive load and design complexity.
Software engineers enforce abstraction using Abstract Classes (classes that cannot be
directly instantiated and contain unimplemented abstract methods) and Interfaces
(contracts defining behaviors that implementing classes must satisfy).
2.3 Inheritance
Inheritance is the structural mechanism by which one class (the child, derived, or
subclass) inherits attributes and methods from an existing class (the parent, base, or
superclass). This promotes code reusability and establishes hierarchical relationships.
Common patterns include Single Inheritance, Multi-level Inheritance, and Hierarchical
Inheritance. Certain languages like Java and C# ban Multiple Inheritance of classes to
eliminate structural ambiguity (the Diamond Problem), resolving it instead via multiple
interface fulfillment.
2.4 Polymorphism
Polymorphism means 'many forms'. It is the capability of an interface or method to
perform differently based on the underlying object executing it. It is split into two
primary types:
Compile-time Polymorphism (Method Overloading): Occurs when multiple
methods in the same class share the exact same name but possess different
parameter signatures (different argument counts or data types). Resolution happens
during program compilation.
Runtime Polymorphism (Method Overriding): Occurs when a child class
provides a specific implementation for a method that is already defined in its parent
class. The execution path is resolved at runtime based on the actual object type via
virtual method lookups (v-tables).
3. Summary of Core Modifiers & Pillars
The following lookup table summarizes how different visibility restrictions shield states
across an object hierarchy:
Access Modifier Visibility within Visibility within Visibility in
Same Class Subclass World / External
Packages
public Fully Accessible Fully Accessible Fully Accessible
protected Fully Accessible Accessible via Blocked / Restricted
Inheritance
private Fully Accessible Blocked / Hidden Blocked / Hidden