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
| Aspect | Procedural | OOP |
|---|---|---|
| Decomposition | Top-down: function → sub-function | Bottom-up: objects → interactions |
| Data + functions | Separate | Encapsulated together |
| Data protection | None (global / args) | Private members |
| Code reuse | Functions (copy / library) | Inheritance + composition |
| Approach | Algorithm-first | Data-first |
| Real-world mapping | Indirect | Natural (entities = objects) |
| Extensibility | Modify existing functions | Inherit and override |
| Language examples | C, Pascal, FORTRAN | C++, 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)
| Concept | Definition |
|---|---|
| Class | Blueprint defining attributes + methods |
| Object | Instance of a class — runtime entity |
| Method / Member function | A function defined inside a class |
| Message passing | Calling a method on an object: obj.method() |
| Dynamic binding | Method to call resolved at runtime |
| Reusability | Inherit; don't rewrite |
| Data hiding | Private members inaccessible outside |
| Genericity | Templates — code that works for any type |
---
Applications of OOP
| Area | Why OOP? |
|---|---|
| GUI applications | Widgets, buttons, windows are natural objects |
| Games | Player, enemy, weapon, level all map to classes |
| Simulation | Real-world entities directly modelled |
| Banking / ERP / CRM | Account, Customer, Order, Invoice are objects |
| Operating systems | Processes, files, sockets — all objects |
| Database engines | Tables, rows, queries — encapsulated |
| Compilers | AST nodes, symbol tables — hierarchies |
| Robotics / IoT | Sensors, motors, controllers — encapsulated objects |
| Web frameworks | Models, views, controllers (MVC) |
---
Benefits of OOP
| Benefit | Detail |
|---|---|
| Reusability | Inherit existing classes, write less code |
| Modularity | Each class is a self-contained module |
| Maintainability | Localised changes; bug in Account class affects only Account |
| Scalability | Easy to add new types without modifying old code (open-closed principle) |
| Real-world modelling | Direct mapping of entities to classes |
| Data security | Private members + controlled access |
| Reduced complexity | Hide implementation behind clean interface |
| Team development | Different developers own different classes |
---
Limitations / Drawbacks of OOP
| Limitation | Detail |
|---|---|
| Steeper learning curve | More concepts than procedural |
| Larger code size | Class boilerplate adds lines |
| Slower execution | Virtual function dispatch, larger memory footprint |
| Overkill for small programs | A 10-line script doesn't need classes |
| Memory overhead | Each object has extra metadata |
| Designing is hard | Bad inheritance hierarchies cause more problems than they solve |
| Not all problems are object-oriented | Algorithmic / data-processing tasks may be cleaner in functional/procedural |
---
History of OOP and C++
| Year | Milestone |
|---|---|
| 1967 | Simula 67 — first OO language (Norway) — invented classes, inheritance |
| 1972 | C invented (Dennis Ritchie, Bell Labs) |
| 1979 | Bjarne Stroustrup starts "C with Classes" at Bell Labs |
| 1983 | Renamed C++ |
| 1985 | First commercial release of C++ |
| 1989 | C++ 2.0 — multiple inheritance, abstract classes |
| 1998 | First ISO standard — C++98 (the IPU baseline) |
| 2003 | C++03 — minor refinements |
| 2011 | C++11 — major modernisation |
| 2014 / 17 / 20 / 23 | C++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 other — account.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
- 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.
- 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.
- 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.
- 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.
- 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).