Object Oriented Concepts

Comprehensive Theory Notes for CBDT Assistant Director (Systems) Exam

1. Introduction to Object-Oriented Programming

Object-Oriented Programming (OOP) is a programming paradigm based on the concept of "objects" that contain both data (attributes) and code (methods).

Procedural vs Object-Oriented Programming

Feature Procedural Object-Oriented
Focus Functions/procedures Objects and data
Data Shared, less secure Encapsulated, secure
Approach Top-down Bottom-up
Reusability Limited High (inheritance, polymorphism)
Examples C, FORTRAN, Pascal Java, C++, Python, C#

Key OOP Concepts

  1. Encapsulation — Data hiding
  2. Abstraction — Hiding complexity
  3. Inheritance — Code reuse
  4. Polymorphism — Multiple forms
  5. Message Passing — Objects communicate via messages

2. Classes and Objects

Class

A class is a blueprint/template for creating objects. It defines:
- Attributes/Fields/Properties (data members)
- Methods/Functions (member functions)
- Constructors/Destructors (special methods)

Object

An object is an instance of a class with:
- State: Values of attributes
- Behavior: Actions via methods
- Identity: Unique identifier

Access Specifiers

Specifier Same Class Derived Class Outside
Private ✅ ❌ ❌
Protected ✅ ✅ ❌
Public ✅ ✅ ✅

Constructors

Special methods called automatically when an object is created.

Type Description
Default No parameters; created by compiler if none defined
Parameterized Takes arguments to initialize object
Copy Creates object from another object of same class
Move (C++11) Transfers resources from temporary object

Destructor

Called automatically when object goes out of scope or is deleted.
- Name: ~ClassName()
- No parameters, no return type
- Called in reverse order of construction

this Pointer (C++) / self (Python)

Static Members

Friend Function/Class

3. Encapsulation

Encapsulation is the bundling of data and methods that operate on that data within a single unit (class), and restricting direct access to some components.

Key Aspects

┌─────────────────────────────┐
│         Class               │
│  - private_data    (hidden) │
│  + public_method() (access) │
│  + get_data()      (getter) │
│  + set_data()      (setter) │
└─────────────────────────────┘

Abstraction vs Encapsulation

Abstraction Encapsulation
Hides complexity (what it does) Hides implementation (how it does)
Achieved via abstract classes, interfaces Achieved via access modifiers
Design level Implementation level
Focuses on external behavior Focuses on internal working

4. Inheritance

Inheritance allows a class (child/derived) to inherit properties and methods from another class (parent/base).

Types of Inheritance

Type Structure Description
Single A → B One parent, one child
Multilevel A → B → C Chain of inheritance
Hierarchical A → B, A → C Multiple children from one parent
Multiple A, B → C Child inherits from multiple parents
Hybrid Combination Mix of two or more types

Note: Java does NOT support multiple inheritance with classes (to avoid diamond problem) but allows it via interfaces.

Modes of Inheritance (C++)

Base Member Public Mode Protected Mode Private Mode
Public Public in derived Protected in derived Private in derived
Protected Protected in derived Protected in derived Private in derived
Private Not accessible Not accessible Not accessible

Diamond Problem

When a class inherits from two classes that share a common base class.

    A
   / \
  B   C
   \ /
    D

Solutions:
- Virtual inheritance (C++) — ensures only one copy of base class
- Interfaces (Java) — avoids diamond problem entirely
- Method resolution order (Python) — uses C3 linearization

Order of Constructor/Destructor Calls

Constructor: Base → Derived (top to bottom)
Destructor: Derived → Base (bottom to top)

5. Polymorphism

Polymorphism means "many forms" — the same interface behaving differently based on the context.

Types of Polymorphism

1. Compile-Time (Static) Polymorphism

Type Description Binding
Function Overloading Same name, different parameters Early/Static
Operator Overloading Same operator, different behavior Early/Static

Function Overloading Rules:
- Same function name
- Different number OR type of parameters
- Return type alone is NOT sufficient for overloading

Operator Overloading:
- Cannot overload: ::, ., .*, ?:, sizeof
- Cannot create new operators
- At least one operand must be user-defined type
- Cannot change precedence or arity

2. Runtime (Dynamic) Polymorphism

Function Overriding:
- Derived class redefines a base class method
- Same signature (name + parameters)
- Requires virtual function (C++) or regular method (Java)
- Resolved at runtime using dynamic binding

Virtual Function (C++)

Abstract Class

Virtual Destructor

6. Abstract Class vs Interface

Feature Abstract Class Interface
Instantiation ❌ Cannot ❌ Cannot
Methods Can have abstract + concrete Only abstract (default in Java 8+)
Variables Any type Public static final (constants)
Constructor Yes No
Multiple Single inheritance (classes) Multiple implementation
Access Any access modifier Public by default
When to use "Is-a" relationship with shared code "Can-do" / contract

Multiple Inheritance via Interfaces (Java)

interface Flyable { void fly(); }
interface Swimmable { void swim(); }
class Duck implements Flyable, Swimmable { ... }

7. UML Diagrams

UML (Unified Modeling Language) is a standard visual modeling language for software systems.

Structural Diagrams

Class Diagram

Shows classes, attributes, methods, and relationships.

┌─────────────────────┐
│      ClassName      │
├─────────────────────┤
│ - privateVar: int   │
│ # protectedVar: str │
│ + publicVar: float  │
├─────────────────────┤
│ + method1(): void   │
│ - method2(): int    │
│ # method3(): str    │
└─────────────────────┘

Relationships in Class Diagrams:

Relationship Symbol Meaning
Association ──→ Uses/connected to
Aggregation ◇──→ "Has-a" (weak; parts can exist independently)
Composition ◆──→ "Has-a" (strong; parts die with whole)
Inheritance ──▷ "Is-a" (generalization)
Realization ─ ─▷ Implements interface
Dependency - - - > Uses temporarily

Behavioral Diagrams

Sequence Diagram

Shows time-ordered message flow between objects.

Object A        Object B        Object C
    │               │               │
    │──message1────>│               │
    │               │──message2────>│
    │               │<───reply──────│
    │<──reply───────│               │
    │               │               │

Use Case Diagram

Shows actors and use cases (functionalities) of the system.

Activity Diagram

Shows workflow or process flow (like a flowchart).
- Start node → Activities → Decisions → Merge → End
- Supports parallel activities (fork/join)
- Swimlanes show responsibility

UML Exam Points

8. Design Patterns

Design patterns are reusable solutions to common software design problems.

Creational Patterns

Singleton Pattern

Ensures a class has only one instance and provides global access to it.

┌───────────────────┐
│    Singleton       │
├───────────────────┤
│ - instance         │
├───────────────────┤
│ - Singleton()      │
│ + getInstance()    │
└───────────────────┘

Implementation: Private constructor, static instance, static getter
Use cases: Logger, configuration manager, database connection pool
Thread safety: Use double-checked locking or synchronization

Factory Pattern

Creates objects without specifying the exact class to create.

┌──────────────┐       ┌───────────────┐
│  Client      │       │  Factory      │
│              │------>| + create()    │
└──────────────┘       └───────┬───────┘
                               │
                    ┌──────────┼──────────┐
                    │          │          │
              ┌─────┴───┐ ┌───┴────┐ ┌───┴────┐
              │Product A │ │Prod. B │ │Prod. C │
              └─────────┘ └────────┘ └────────┘

Types:
- Simple Factory: Single method creates different types
- Factory Method: Subclass decides which class to instantiate
- Abstract Factory: Factory of factories

Builder Pattern

Constructs complex objects step by step.
Use case: Building complex objects with many optional parameters

Structural Patterns

Adapter Pattern

Converts interface of one class into another interface clients expect.
- Like a power adapter for different plug types
- Use case: Integrating legacy code with new systems

Decorator Pattern

Dynamically adds responsibilities to an object without modifying its class.
- Wraps the original object
- Use case: I/O streams in Java (BufferedReader wrapping FileReader)

Facade Pattern

Provides a simplified interface to a complex subsystem.
- Use case: API simplification, library interfaces

Behavioral Patterns

Observer Pattern

Defines one-to-many dependency; when one object changes state, all dependents are notified.

┌──────────┐         ┌──────────────┐
│  Subject │         │  Observer     │
│          │────────>| + update()    │
│+attach() │         └──────────────┘
│+notify() │
└──────────┘

Use cases: Event handling, MVC, stock market monitoring, publish-subscribe systems

Strategy Pattern

Defines a family of algorithms, encapsulates each one, and makes them interchangeable.

┌──────────────┐       ┌─────────────────┐
│  Context     │       │  Strategy        │
│              │──────>| + execute()     │
│+setStrategy()│       └────────┬────────┘
└──────────────┘          ┌─────┼─────┐
                          │     │     │
                    Strat.A  Strat.B  Strat.C

Use cases: Different sorting algorithms, compression strategies, payment methods

MVC Pattern (Model-View-Controller)

Component Responsibility
Model Data, business logic, state
View User interface, display
Controller Input handling, updates model

Flow: User → Controller → Model → View → User
Use cases: Web frameworks (Django, Spring MVC, ASP.NET MVC), desktop applications

Design Pattern Comparison

Pattern Category Purpose
Singleton Creational Single instance
Factory Creational Object creation without specifying class
Builder Creational Step-by-step complex object construction
Adapter Structural Interface conversion
Decorator Dynamic Add responsibilities
Facade Structural Simplified interface
Observer Behavioral One-to-many notification
Strategy Behavioral Interchangeable algorithms
MVC Architectural Separation of concerns

9. SOLID Principles

SOLID is an acronym for five design principles that make software more understandable, flexible, and maintainable.

S — Single Responsibility Principle (SRP)

A class should have one and only one reason to change.

Each class should be responsible for a single part of the functionality.
- Violation: A class handling both database operations and email sending
- Solution: Separate into DatabaseManager and EmailService classes

O — Open/Closed Principle (OCP)

Software entities should be open for extension but closed for modification.

Add new functionality by extending existing code, not by modifying it.
- Violation: Adding new shape requires modifying area calculation method
- Solution: Use abstract Shape class with derived classes Circle, Rectangle, etc.

L — Liskov Substitution Principle (LSP)

Objects of a superclass should be replaceable with objects of its subclasses without affecting correctness.

If S is a subtype of T, then objects of T can be replaced with objects of S.
- Violation: Square inheriting from Rectangle but changing width/height behavior
- Solution: Use composition instead of inheritance in such cases

I — Interface Segregation Principle (ISP)

Clients should not be forced to depend on interfaces they don't use.

Prefer many specific interfaces over one general-purpose interface.
- Violation: Single IWorker interface with work(), eat(), sleep() — robots don't eat/sleep
- Solution: Separate into IWorkable and IEatable interfaces

D — Dependency Inversion Principle (DIP)

High-level modules should not depend on low-level modules. Both should depend on abstractions.

Depend on interfaces/abstract classes, not concrete implementations.
- Violation: OrderService directly creates MySQLDatabase instance
- Solution: OrderService depends on Database interface; MySQLDatabase implements it

┌──────────────┐     ┌─────────────┐
│  High-Level  │────>│  Abstraction │
│  Module      │     │ (Interface)  │
└──────────────┘     └──────┬───────┘
                            │
                     ┌──────┴───────┐
                     │  Low-Level    │
                     │  Module       │
                     └──────────────┘

10. Aggregation vs Composition

Both are types of association (whole-part relationships).

Feature Aggregation Composition
Symbol Hollow diamond (◇) Filled diamond (◆)
Relationship "Has-a" (weak) "Has-a" (strong)
Lifetime Parts exist independently Parts die with whole
Dependency Low High
Example University → Departments House → Rooms

Aggregation: If university closes, departments may still exist (can move to another university)
Composition: If house is destroyed, rooms are destroyed with it

11. Key OOP Concepts Summary

Concept Description Example
Class Blueprint for objects class Car { ... }
Object Instance of class Car myCar = new Car();
Encapsulation Data hiding + controlled access Private fields + getters/setters
Abstraction Hiding implementation complexity Abstract class, interface
Inheritance Code reuse via parent-child class Dog extends Animal
Polymorphism Same interface, different behavior Method overriding, overloading
Message Passing Objects communicate via method calls obj.method()
Coupling Degree of interdependence between modules Low coupling = good
Cohesion Degree to which elements belong together High cohesion = good

Coupling vs Cohesion

Low High
Coupling ✅ Good (independent modules) ❌ Bad (tightly dependent)
Cohesion ❌ Bad (unrelated elements) ✅ Good (related elements)

Goal: Low coupling, High cohesion

12. Additional Important Concepts

Method Overloading vs Overriding

Feature Overloading Overriding
Binding Compile-time Runtime
Class Same class Parent-child classes
Signature Must differ Must be same
Return type Can differ Must be same (or covariant)
Polymorphism type Static Dynamic

Shallow Copy vs Deep Copy

Type Description
Shallow Copy Copies object but not referenced objects (shared references)
Deep Copy Copies object AND all referenced objects (independent copies)

Virtual Function Table (vtable)

Abstract Class vs Concrete Class

Feature Abstract Class Concrete Class
Instantiation ❌ Cannot ✅ Can
Abstract methods At least one None
Purpose Base class for inheritance Direct use

Composition over Inheritance

13. Exam Tips

Practice Questions

8 MCQs for Object Oriented Concepts with detailed explanations.

Q1. Consider the following about is a blueprint/template for creating objects. It defines:

-...

✅ Correct Answer: Option D

Explanation:
The correct answer is Option D — is a blueprint/template for creating objects. It defines:
-.

This is a standard concept in Object Oriented Concepts. The answer follows from the fundamental definitions and properties covered in this topic.

Why other options are incorrect:
- Option A (It applies only to sequential processing models...) — This does not correctly answer the question as it either misstates the concept or refers to a different context.
- Option B (It requires a minimum of O(n²) time complexity...) — This does not correctly answer the question as it either misstates the concept or refers to a different context.
- Option C (It is not applicable in distributed systems...) — This does not correctly answer the question as it either misstates the concept or refers to a different context.

Q2. Consider the following about is an instance of a class with:

-...

- A. is an instance of a class with:

✅ Correct Answer: Option A

Explanation:
The correct answer is Option A — is an instance of a class with:
-.

This is a standard concept in Object Oriented Concepts. The answer follows from the fundamental definitions and properties covered in this topic.

Why other options are incorrect:
- Option B (It applies only to sequential processing models...) — This does not correctly answer the question as it either misstates the concept or refers to a different context.
- Option C (It is not applicable in distributed systems...) — This does not correctly answer the question as it either misstates the concept or refers to a different context.
- Option D (It requires a minimum of O(n²) time complexity...) — This does not correctly answer the question as it either misstates the concept or refers to a different context.

Q3. Which of the following best describes when an object?

Object-Oriented Programming (OOP) is a
- B. is an instance of a class with:
-
- C. created.
- D. is a blueprint/template for creating objects. It defines:
-

✅ Correct Answer: Option C

Explanation:
The correct answer is Option C — created..

This is a standard concept in Object Oriented Concepts. The answer follows from the fundamental definitions and properties covered in this topic.

Why other options are incorrect:
- Option A (Introduction to Object-Oriented Programming

Object-Oriented Programming (OOP)...) — This does not correctly answer the question as it either misstates the concept or refers to a different context.
- Option B (is an instance of a class with:
-...) — This does not correctly answer the question as it either misstates the concept or refers to a different context.
- Option D** (is a blueprint/template for creating objects. It defines:
-...) — This does not correctly answer the question as it either misstates the concept or refers to a different context.

Q4. Consider the following about Introduction to Object-Oriented Programming

**Object-Orient...

Object-Oriented Programming (OOP) is a

✅ Correct Answer: Option D

Explanation:
The correct answer is Option D — Introduction to Object-Oriented Programming

Object-Oriented Programming (OOP) is a.

This is a standard concept in Object Oriented Concepts. The answer follows from the fundamental definitions and properties covered in this topic.

Why other options are incorrect:
- Option A (It applies only to sequential processing models...) — This does not correctly answer the question as it either misstates the concept or refers to a different context.
- Option B (It is not applicable in distributed systems...) — This does not correctly answer the question as it either misstates the concept or refers to a different context.
- Option C (It requires a minimum of O(n²) time complexity...) — This does not correctly answer the question as it either misstates the concept or refers to a different context.

Q5. Consider the following about It defines:

✅ Correct Answer: Option C

Explanation:
The correct answer is Option C — It defines:
- Attributes/Fields/Properties (data members).

This is a standard concept in Object Oriented Concepts. The answer follows from the fundamental definitions and properties covered in this topic.

Why other options are incorrect:
- Option A (It applies only to sequential processing models...) — This does not correctly answer the question as it either misstates the concept or refers to a different context.
- Option B (It is not applicable in distributed systems...) — This does not correctly answer the question as it either misstates the concept or refers to a different context.
- Option D (It requires a minimum of O(n²) time complexity...) — This does not correctly answer the question as it either misstates the concept or refers to a different context.

Q6. Consider the following about is an instance of a class with:

✅ Correct Answer: Option C

Explanation:
The correct answer is Option C — is an instance of a class with:
- **State.

This is a standard concept in Object Oriented Concepts. The answer follows from the fundamental definitions and properties covered in this topic.

Why other options are incorrect:
- Option A (It is not applicable in distributed systems...) — This does not correctly answer the question as it either misstates the concept or refers to a different context.
- Option B (It requires a minimum of O(n²) time complexity...) — This does not correctly answer the question as it either misstates the concept or refers to a different context.
- Option D (It applies only to sequential processing models...) — This does not correctly answer the question as it either misstates the concept or refers to a different context.

Q7. Consider the following about Behavior:** Actions via methods...

✅ Correct Answer: Option A

Explanation:
The correct answer is Option A — Behavior:** Actions via methods.

This is a standard concept in Object Oriented Concepts. The answer follows from the fundamental definitions and properties covered in this topic.

Why other options are incorrect:
- Option B (It applies only to sequential processing models...) — This does not correctly answer the question as it either misstates the concept or refers to a different context.
- Option C (It requires a minimum of O(n²) time complexity...) — This does not correctly answer the question as it either misstates the concept or refers to a different context.
- Option D (It is not applicable in distributed systems...) — This does not correctly answer the question as it either misstates the concept or refers to a different context.

Q8. Consider the following about Identity:** Unique identifier...

✅ Correct Answer: Option C

Explanation:
The correct answer is Option C — Identity:** Unique identifier.

This is a standard concept in Object Oriented Concepts. The answer follows from the fundamental definitions and properties covered in this topic.

Why other options are incorrect:
- Option A (It applies only to sequential processing models...) — This does not correctly answer the question as it either misstates the concept or refers to a different context.
- Option B (It is not applicable in distributed systems...) — This does not correctly answer the question as it either misstates the concept or refers to a different context.
- Option D (It requires a minimum of O(n²) time complexity...) — This does not correctly answer the question as it either misstates the concept or refers to a different context.