OOP · 1 min
Does composition mean never using inheritance?
Learn how composition keeps classes loosely coupled using collaborators, and why it differs from rigid compile-time inheritance.
The quiz
What does "favour composition over inheritance" advise?
- Build behaviour by holding other objects that do part of the work, rather than by extending classes
- Never use inheritance at all
- Put every class in its own file
- Use interfaces only for constants
Show the answer
A. Build behaviour by holding other objects that do part of the work, rather than by extending classes
Transcript
Saying this rule means you should never use inheritance will get you rejected.
Inheritance models an is-a relationship where Car is a Vehicle, while composition means Car has an Engine collaborator doing part of the work.
Instead of extending classes, your Car class holds an Engine and a Logger, delegating tasks directly without being tied to parent internals.
Now the part most people miss: inheritance locks internals at compile time, but composition lets pieces be swapped or mocked cleanly.
This principle builds system behaviour by holding collaborator objects to stay loosely coupled, rather than staying tightly coupled through rigid parent classes.
What does favour composition over inheritance actually advise you to do? Pause the video right now and choose option A, B, C, or D.
The correct answer is A. Option B is completely wrong because this timeless design advice never tells you to eliminate inheritance altogether.
Save this quick guide before your next technical interview round, and practice real system design and object-oriented programming questions on InternDoor.
