OOP principles overview in C++ - Time & Space Complexity
When we use object-oriented programming (OOP), we organize code into objects and classes. It is important to understand how the time it takes to run our programs grows as we use these OOP ideas.
We want to know how the main actions in OOP affect the program's speed as the program gets bigger.
Analyze the time complexity of the following code snippet.
class Box {
public:
int length, width, height;
Box(int l, int w, int h) : length(l), width(w), height(h) {}
int volume() {
return length * width * height;
}
};
void printVolumes(Box boxes[], int n) {
for (int i = 0; i < n; i++) {
std::cout << boxes[i].volume() << std::endl;
}
}
This code defines a Box class with a method to calculate volume. Then it prints the volume of each box in an array.
- Primary operation: Looping through each box and calling the volume method.
- How many times: The loop runs once for each box, so n times.
As the number of boxes increases, the total work grows in a straight line with the number of boxes.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | About 10 volume calculations and prints |
| 100 | About 100 volume calculations and prints |
| 1000 | About 1000 volume calculations and prints |
Pattern observation: Doubling the number of boxes doubles the work done.
Time Complexity: O(n)
This means the time to run grows directly with the number of boxes we process.
[X] Wrong: "Calling a method inside a loop makes the program slower in a way that changes the overall time complexity."
[OK] Correct: Each method call here does a simple calculation, so it only adds a small fixed amount of work per item. The overall time still grows linearly with the number of items.
Understanding how loops and method calls affect time helps you explain your code clearly and shows you know how programs scale. This skill is useful when discussing your designs and choices.
"What if the volume method itself contained a loop over some internal data? How would the time complexity change?"
Practice
Solution
Step 1: Recall the four main OOP principles
The four main principles are encapsulation, inheritance, polymorphism, and abstraction.Step 2: Identify the option not in the list
Compilation is a process of converting code, not an OOP principle.Final Answer:
Compilation -> Option BQuick Check:
OOP principles exclude compilation [OK]
- Confusing compilation with abstraction
- Mixing OOP principles with programming processes
Solution
Step 1: Identify the C++ keyword for defining a class
In C++, the keyword to define a class isclass.Step 2: Check other options
structdefines a structure,objectis not a keyword, anddefineis for macros.Final Answer:
class -> Option AQuick Check:
Useclassto define classes [OK]
- Confusing struct with class
- Using 'object' as a keyword
- Mixing macros with class definition
class Animal {
public:
void sound() { std::cout << "Animal sound"; }
};
class Dog : public Animal {
public:
void sound() { std::cout << "Bark"; }
};
int main() {
Animal* a = new Dog();
a->sound();
delete a;
return 0;
}Solution
Step 1: Understand method call without virtual keyword
Thesoundmethod is not virtual, so the pointer typeAnimal*calls Animal's method.Step 2: Determine output
Sincesoundis not virtual,Animal soundis printed.Final Answer:
Animal sound -> Option DQuick Check:
Non-virtual method calls base class method [OK]
- Assuming polymorphism without virtual
- Expecting derived class method call
- Ignoring pointer type effect
class Vehicle {
private:
int speed;
public:
void setSpeed(int s) { speed = s; }
};
int main() {
Vehicle v;
v.speed = 100;
return 0;
}Solution
Step 1: Check access to private member
The memberspeedis private and cannot be accessed directly outside the class.Step 2: Identify the error in main()
Trying to assignv.speed = 100;causes an access violation error.Final Answer:
Cannot access private member 'speed' directly -> Option CQuick Check:
Private members need public methods for access [OK]
- Trying to access private variables directly
- Ignoring access specifiers
- Assuming public by default
Shape defines a method area() but each derived class calculates area differently. Which OOP principle does this best demonstrate?Solution
Step 1: Understand the scenario of different area calculations
Each derived class implementsarea()differently, but shares the same interface.Step 2: Identify the OOP principle
This is polymorphism: same method name, different behaviors in subclasses.Final Answer:
Polymorphism -> Option AQuick Check:
Same method, different behaviors = Polymorphism [OK]
- Confusing with inheritance or abstraction
- Thinking encapsulation means method overriding
Ready to prove it?
Pass the test and this pattern moves unknown
