Imagine you are tasked with designing a car in a software system. Your first instinct, guided by early lessons in object-oriented programming, might be to think about what a car "is." A car needs an engine to work. An engine has start() and stop() methods. So why not just have the Car class inherit from Engine?

This model immediately feels wrong. A car is not an engine. A car has an engine. This simple distinction in language is the key to understanding one of the most powerful principles in object-oriented design: Favor Composition over Inheritance.

Inheritance creates an "is-a" relationship. Composition creates a "has-a" relationship. While inheritance is a powerful tool for creating subtypes, its misuse leads to rigid, fragile, and tangled systems.

Composition, on the other hand, allows you to build complex objects by assembling smaller, independent, and interchangeable parts. Much like building with LEGO blocks, you snap components together, and you can swap any piece without rebuilding the entire structure.

This chapter will explore the classic debate between these two forms of code reuse, revealing why the simple act of "having" is often far more flexible and powerful than the act of "being."