Siksha Sarovar

Siksha Sarovar (sikshasarovar.com) is a free educational web application that helps students in India learn programming and prepare for academic and competitive exams. The platform offers structured coding courses (C, C++, Python, Java, HTML, CSS, PHP, Power BI, AI, Machine Learning, Data Science), complete university curriculum notes for BCA/MCA students with previous year question papers, Class 10 and Class 12 CBSE/HBSE school notes, and dedicated preparation material for SSC, UPSC, Banking, Railway and other government exams. Browsing the site is completely free and requires no account. Users may optionally sign in with Google solely to save their learning progress, quiz scores and personal preferences across devices.

Privacy Policy | Terms of Service | Contact Siksha Sarovar | About Siksha Sarovar

v4.0.9 · PWA
Siksha Sarovar logo
Siksha Sarovar
Your Learning Universe

Siksha Sarovar is a free e-learning platform for coding courses, BCA university notes and competitive exam preparation. Optional Google sign-in saves your learning progress across devices.

Initializing knowledge base…
Compiling modules 0%

1.1 OOP Paradigm — Procedural vs OOP, Concepts, Benefits

Lesson 3 of 22 in the free Object Oriented Programming with C++ notes on Siksha Sarovar, written by Rohit Jangra.

1.1 OOP Paradigm

Procedural Programming — what came before

Procedural programming (C, Pascal, FORTRAN) decomposes a problem into a sequence of procedures (functions). Data and the functions that operate on it are separate.

// Procedural style — C
struct Student {
    int id;
    char name[50];
    float marks;
};

void displayStudent(struct Student s) {
    printf("ID: %d, Name: %s, Marks: %.2f\n", s.id, s.name, s.marks);
}

int main() {
    struct Student s = {101, "Rohit", 88.5};
    displayStudent(s);
    return 0;
}

Characteristics of procedural programming

  • Top-down design
  • Functions and data live separately
  • Data is global or passed around as arguments
  • Emphasis on the algorithm
  • Best for small, well-defined problems

Where procedural fails at scale

  • 1,000 functions × 100 structs → exponential coupling
  • Data is unprotected — any function can corrupt it
  • Hard to extend without modifying existing code
  • Real-world entities (Bank Account, Customer, Order) mapped awkwardly to struct + functions

---

Object-Oriented Programming

OOP treats software as a collection of objects, each combining data (state) and functions (behaviour). The class is the blueprint; the object is the instance.

// OOP style — C++
class Student {
private:
    int id;
    string name;
    float marks;
public:
    Student(int i, string n, float m) : id(i), name(n), marks(m) {}
    void display() {
        cout << "ID: " << id << ", Name: " << name
             << ", Marks: " << marks << endl;
    }
};

int main() {
    Student s(101, "Rohit", 88.5);
    s.display();
    return 0;
}

Differences

AspectProceduralOOP
DecompositionTop-down: function → sub-functionBottom-up: objects → interactions
Data + functionsSeparateEncapsulated together
Data protectionNone (global / args)Private members
Code reuseFunctions (copy / library)Inheritance + composition
ApproachAlgorithm-firstData-first
Real-world mappingIndirectNatural (entities = objects)
ExtensibilityModify existing functionsInherit and override
Language examplesC, Pascal, FORTRANC++, Java, C#, Python, Ruby
Memory aid: Procedural = "What steps?" — OOP = "What objects, and what can they do?"

---

Basic Concepts of OOP — the Four Pillars

1. Encapsulation

Encapsulation = bundling data and the operations that act on it into a single unit (class), and hiding the internal details.

class BankAccount {
private:
    double balance;        // hidden — internal state

public:
    void deposit(double amount) {
        if (amount > 0) balance += amount;
    }

    double getBalance() {
        return balance;
    }
};

Benefits:

  • Internal state cannot be corrupted by external code
  • Implementation can change without affecting users
  • Easier to reason about — clear contract

2. Abstraction

Abstraction = showing only the essential features of an object, hiding the unnecessary details. Often achieved via abstract classes / interfaces.

class Stack {
public:
    void push(int x);
    int  pop();
    bool empty();
private:
    int data[100];   // implementation detail — user doesn't care
    int top;
};

The user knows: "I can push, pop, check empty." They don't know — and don't need to know — how the stack is implemented (array, linked list, dynamic vector).

3. Inheritance

Inheritance = creating new classes from existing classes, reusing properties and behaviour.

class Vehicle {
public:
    int wheels;
    void start() { cout << "Engine starts\n"; }
};

class Car : public Vehicle {   // Car inherits from Vehicle
public:
    int seats;
    void honk() { cout << "Beep!\n"; }
};

Car c;
c.start();   // inherited from Vehicle
c.honk();    // own method

4. Polymorphism

Polymorphism = "many forms". The same operation can behave differently for different object types.

class Shape {
public:
    virtual void draw() {
        cout << "Drawing a shape\n";
    }
};

class Circle : public Shape {
public:
    void draw() override {
        cout << "Drawing a circle\n";
    }
};

Shape* s = new Circle();
s->draw();   // prints "Drawing a circle" — runtime polymorphism
Exam tip: When asked to "explain OOP concepts," structure your answer as the 4 pillars + one C++ example per pillar.

---

Other OOP Concepts (often examined together)

ConceptDefinition
ClassBlueprint defining attributes + methods
ObjectInstance of a class — runtime entity
Method / Member functionA function defined inside a class
Message passingCalling a method on an object: obj.method()
Dynamic bindingMethod to call resolved at runtime
ReusabilityInherit; don't rewrite
Data hidingPrivate members inaccessible outside
GenericityTemplates — code that works for any type

---

Applications of OOP

AreaWhy OOP?
GUI applicationsWidgets, buttons, windows are natural objects
GamesPlayer, enemy, weapon, level all map to classes
SimulationReal-world entities directly modelled
Banking / ERP / CRMAccount, Customer, Order, Invoice are objects
Operating systemsProcesses, files, sockets — all objects
Database enginesTables, rows, queries — encapsulated
CompilersAST nodes, symbol tables — hierarchies
Robotics / IoTSensors, motors, controllers — encapsulated objects
Web frameworksModels, views, controllers (MVC)

---

Benefits of OOP

BenefitDetail
ReusabilityInherit existing classes, write less code
ModularityEach class is a self-contained module
MaintainabilityLocalised changes; bug in Account class affects only Account
ScalabilityEasy to add new types without modifying old code (open-closed principle)
Real-world modellingDirect mapping of entities to classes
Data securityPrivate members + controlled access
Reduced complexityHide implementation behind clean interface
Team developmentDifferent developers own different classes

---

Limitations / Drawbacks of OOP

LimitationDetail
Steeper learning curveMore concepts than procedural
Larger code sizeClass boilerplate adds lines
Slower executionVirtual function dispatch, larger memory footprint
Overkill for small programsA 10-line script doesn't need classes
Memory overheadEach object has extra metadata
Designing is hardBad inheritance hierarchies cause more problems than they solve
Not all problems are object-orientedAlgorithmic / data-processing tasks may be cleaner in functional/procedural

---

History of OOP and C++

YearMilestone
1967Simula 67 — first OO language (Norway) — invented classes, inheritance
1972C invented (Dennis Ritchie, Bell Labs)
1979Bjarne Stroustrup starts "C with Classes" at Bell Labs
1983Renamed C++
1985First commercial release of C++
1989C++ 2.0 — multiple inheritance, abstract classes
1998First ISO standard — C++98 (the IPU baseline)
2003C++03 — minor refinements
2011C++11 — major modernisation
2014 / 17 / 20 / 23C++14 / 17 / 20 / 23 — continuing evolution

---

Key Terms — Lesson 1.1

The terms below are the foundational OOP vocabulary every later lesson assumes. Each appears in nearly every Unit-I PYQ on OOP.

Object-Oriented Programming (OOP) — A programming paradigm where software is organised around objects that combine data (state) and functions (behaviour) into single units, with classes acting as blueprints. OOP emerged in 1967 with Simula and was popularised in industry by Smalltalk (1972), C++ (1979), and Java (1995).

Procedural Programming — A paradigm where the program is decomposed into a sequence of procedures (functions) that operate on separately defined data structures. Data is global or passed around as arguments. C, Pascal, and FORTRAN are classical procedural languages. Procedural code is naturally top-down; OOP is naturally bottom-up.

Class — A blueprint that defines the attributes (data members) and behaviours (member functions / methods) common to all objects of a type. A class is a type definition, not a runtime entity; it does not allocate memory by itself.

Object — A runtime instance of a class — a concrete entity with its own copy of the class's data members and access to its member functions. An object is to a class what a variable is to a type. The act of creating an object is called instantiation.

Instance / Instantiation — A specific object created from a class. Instantiation is the act of creating that object — declaring Student s; instantiates the Student class.

Member Function / Method — A function defined inside a class that operates on the class's data. Member functions are invoked through an object using the dot operator: s.display(). They have implicit access to the object's data via the this pointer.

Encapsulation — The first OOP pillar: bundling data and the functions that operate on that data together inside a class, and hiding the internal details behind an access barrier. Encapsulation makes the internal state safe from accidental corruption.

Abstraction — The second OOP pillar: representing only the essential features of an entity while hiding implementation details. A Stack class exposes push, pop, empty; the user neither knows nor cares whether it uses an array, a linked list, or a deque internally.

Inheritance — The third OOP pillar: deriving a new class (derived/child) from an existing class (base/parent), reusing its members. Inheritance models the "is-a" relationship — a Car is a Vehicle, an Employee is a Person.

Polymorphism — The fourth OOP pillar: the same operation behaves differently on different types. Greek for "many forms." Two forms: compile-time polymorphism (function overloading, operator overloading, templates) and runtime polymorphism (virtual functions, dynamic binding).

Message Passing — The conceptual model of OOP where objects communicate by calling methods on each otheraccount.deposit(100) is a "deposit" message sent to the account object. The terminology comes from Smalltalk; in C++ we usually just say "method call."

Data Member / Attribute / Field — A variable declared inside a class that holds part of each object's state. Each object has its own copy of the data members.

Access Specifier — A keyword (public, private, protected) that controls visibility of class members. Private members are accessible only within the class. Public members are accessible from anywhere. Protected members are accessible within the class and its derived classes.

Data Hiding — The principle that an object's internal state is hidden from external code, accessible only through the class's public interface. Achieved using the private access specifier. Data hiding is what makes encapsulation safe.

Information Hiding (Parnas) — David Parnas's broader 1972 principle: each module hides a design decision that is likely to change, so that change can be made without rippling through the system. Data hiding is one form of information hiding.

Reusability — The OOP benefit that existing classes can be reused in new contexts via inheritance (extend an existing class), composition (use it as a member), templates (parameterise it on type), or simply by linking in libraries that contain it.

Dynamic Binding / Late Binding — The mechanism by which the correct method to call is determined at runtime, not at compile time, based on the actual object type. In C++, dynamic binding is enabled by declaring methods virtual. Contrast with static binding (compile-time resolution, the default).

Genericity / Generic Programming — Writing code that works for any type, deferring the type choice to the user. In C++ this is implemented via templates. std::vector<int> and std::vector<string> are two instantiations of the same template; the algorithm is written once.

Simula 67 — The 1967 Norwegian language (Ole-Johan Dahl and Kristen Nygaard) that invented classes, objects, inheritance, and dynamic binding. The direct ancestor of every OO language; recognised with the ACM Turing Award (2001).

Bjarne Stroustrup — Danish computer scientist at Bell Labs who created C++ in 1979, originally as "C with Classes." Stroustrup remains active in the C++ committee and is the principal author of The C++ Programming Language, the canonical reference.

C++98 / C++03 / C++11 / C++14 / C++17 / C++20 / C++23 — The versions of the ISO C++ standard. C++98 is the academic baseline used in most BCA syllabi. C++11 is the major modernisation that introduced auto, lambdas, smart pointers, move semantics, range-based for, and many other features. C++17/20/23 continue evolving the language.

Composition vs Inheritance — Two ways to reuse a class. Composition is "has-a" — a Car has an Engine (Engine is a member of Car). Inheritance is "is-a" — a Sports Car is a Car. Modern OO advice: "prefer composition over inheritance" because composition is more flexible and avoids the brittleness of deep class hierarchies.

Open-Closed Principle (OCP) — One of the SOLID principles: classes should be open for extension but closed for modification. New behaviour is added by writing new code (a new subclass, a new strategy), not by modifying existing code. Achieved primarily through polymorphism.

Multi-Paradigm Language — A language that supports more than one programming paradigm. C++ supports procedural (C-style), OOP (classes), generic (templates), and functional (lambdas) programming. Python, Scala, and Rust are similarly multi-paradigm. Pure-paradigm languages (Haskell — functional, Smalltalk — pure OO) are rare in industry.

---

Study deep

  1. OOP is about scaling complexity, not solving small problems. A 100-line script doesn't benefit from OOP. A 100,000-line system collapses without it. Always pick the paradigm that fits the problem size.
  1. C++ is a multi-paradigm language. It supports procedural (you can write C-style C++), OOP, generic (templates), and functional (lambdas in C++11+). The IPU syllabus focuses on OOP but real-world C++ uses all four.
  1. The four pillars are interconnected. Encapsulation enables abstraction. Inheritance + virtual functions enable polymorphism. Abstraction is impossible without encapsulation. They are a system, not a checklist.
  1. OOP's biggest critique: hierarchies. Many "OOP gone wrong" stories involve deep inheritance trees. Modern advice: prefer composition over inheritance. C++ supports both — composition is using objects of other classes as members.
  1. Procedural is not "outdated." Linux kernel, Git, SQLite are all C. For systems software where performance is paramount, procedural still wins. OOP is one tool, not the only tool.
PYQ pattern (very common): "Differentiate procedural and object-oriented programming. List the benefits of OOP." — Tabulate 7-8 differences; list 5-6 benefits with one-line explanations; close with one example (Bank Account class).
PYQ pattern: "Explain the basic concepts of OOP." — Define + code-example each of the 4 pillars (encapsulation, abstraction, inheritance, polymorphism); list 5-6 supporting concepts (class, object, method, message-passing, dynamic binding, reusability).