Inheritance and Composition both are the fundamental concepts in OOP. Let's first understand them first then we just talk about the differences.
What is inheritance?
Inheritance is a process in which one object acquires all the properties and behaviors of its parent object automatically. It builds an is-a relationship model between objects
What is composition?
It allows a class that references one or more objects of other classes in instances and that builds a has-a relationship model between objects.
Example:
Suppose we have to design 3 models for Samsung. Let's say the model would be Samsung S series Note Series, A series. So the basic features of these all phones are
- have an AMOLED screen.
- have USB-c fast charging.
- have 5g connectivity.
So we as a programmer can make a generic type/class to fulfill those bare minimum functionality on it and inherit from it so that we can
- reduce duplicate.
- reuse most of the common functions.
- can have more specific functionality depending on the manufacturers. That's great! Now we can focus on each class independently without repeating all of the code by ourselves. That's inheritance.
Now we will design this very same example with a different mindset with it. Suppose we want all of our basic functionality decoupled as components so that we can compose/reuse that individual component and connect those properties to our concrete classes (Model series e.g: A/S/Note series). That's the composition pattern.
Problem:
The problem arrives if your architecture depends on deep inheritance too much. What if at one crucial moment it will overlap with other subclasses. Then a clear way to solve this is to create a special type of inheritance. That's should be the case. Everything should befall into the general way. Therefore composition comes real handy. Let's dive into another example.
Here, we can see we have categorized and built a tree structure for the whole product lineup. That's fantastic! But what if the product/project manager give the next few requirements as
- The S-Pen feature should also be included in the S series.
- High refresh rate can also be included in the Note series.
Temp Solution:
Now that's a problem to fix without balancing the tree right? Okay, so we will come up with this to fix this.
Observation:
We have fixed this issue! Horray! But did you notice the special case that came up with this inheritance tree structure? But if your project manager came up with some other mashup requirements that may befall into both series, your architecture will be in trouble. Yes, you can introduce a special case and bobs your uncle but A true architecture should not encounter the special case, if it did you designed it in the wrong way!. There comes the composition. That's all fuzz about! If you decoupled all the components at the very first, you can compose each entity within another entity.
My Take:
It's not that Inheritance is bad or Composition is super good. They both have their places. Sometimes you need able to define a IS-A relationship and HAS-A relationship along the way! It's just how you designed stuff and how you see a problem, all that's matters!
Happy Learning 🎈🎈