How do you choose the right level of inheritance for your classes?

Inheritance is a powerful feature of object oriented design that allows you to reuse and extend existing code. However, it also comes with some challenges and trade-offs. How do you decide when to use inheritance, how deep to make your inheritance hierarchy, and how to avoid common pitfalls? In this article, we will explore some principles and guidelines that can help you choose the right level of inheritance for your classes.

1 Benefits of inheritance

Inheritance enables you to create new classes that inherit the attributes and methods of existing classes. This can reduce code duplication, improve readability, and facilitate polymorphism. Polymorphism is the ability of objects to behave differently depending on their type, which can make your code more flexible and adaptable. For example, you can have a superclass called Animal that defines common attributes and methods for all animals, and then create subclasses like Dog, Cat, and Bird that inherit from Animal and add specific features or behaviors.

Add your perspective

Jaroslaw Zelinski

Principal Consultant, Business Software & Systems Designer. #MBSE #MDE expert using #UML #BPMN #SysML
Report contribution
I say: never use inheritance in the Domain Model.... It is break encapsulation... Dziedziczenie uzależnia od siebie elementu kodu i czyni całą architekturę monolitem struktury dziedziczenia.

Translated

Like

Unhelpful

2 Drawbacks of inheritance

Inheritance also has some drawbacks that you need to be aware of. One of them is tight coupling, which means that the subclasses depend heavily on the superclass and any changes in the superclass can affect the subclasses. This can make your code more fragile and harder to maintain. Another drawback is the risk of creating overly complex and deep inheritance hierarchies that can confuse developers and users. For example, if you have a class called Vehicle that has subclasses like Car, Truck, and Bike, and then you create another subclass of Car called ElectricCar, you might end up with a lot of inherited attributes and methods that are not relevant or appropriate for ElectricCar.

Add your perspective

3 Liskov substitution principle

One way to avoid some of the problems of inheritance is to follow the Liskov substitution principle, which states that any subclass should be able to substitute its superclass without breaking the functionality or expectations of the code. In other words, the subclass should not violate the contract or the behavior of the superclass. For example, if you have a method that accepts an Animal as a parameter and expects it to have a method called makeSound, then any subclass of Animal should also have a makeSound method that produces a reasonable sound for that animal. You should not create a subclass of Animal called Rock that does not have a makeSound method or has a makeSound method that throws an exception.

Add your perspective

Paulo Zemek

Software Engineer - I talk to computers and they understand me even without AI, we just speak the same language
Report contribution
Most programming articles should stop using "real world" analogies and just focus on "game objects". It is way simpler for most people to understand methods that they would see in a game character, than try to put "animals" or "cars" as programming objects when the real world is so complex already.

Like

Unhelpful

4 Composition over inheritance

Another way to avoid some of the problems of inheritance is to use composition over inheritance, which means that instead of creating subclasses that inherit from a superclass, you create classes that contain or use other classes as components. This can reduce coupling, increase cohesion, and enhance modularity. Cohesion is the degree to which the elements of a class are related and focused on a single purpose. Modularity is the degree to which the classes are independent and can be reused or changed easily. For example, instead of creating a subclass of Vehicle called ElectricCar that inherits all the attributes and methods of Vehicle, you can create a class called ElectricCar that has a Vehicle as a component and adds or overrides some attributes and methods related to electric power.

Add your perspective

Paulo Zemek

Software Engineer - I talk to computers and they understand me even without AI, we just speak the same language
Report contribution
I keep seeing this being said, and I keep saying it is just plain wrong. It is not that we should use composition over inheritance... is that they solve different problems (but have just a very small area where they touch). If your class wants to create a window, it doesn't need to "be" a window. If your class wants to access a database, it doesn't need to "be" or inherit a database object. You just use them (have references to them)... which leads to composition. Inheritance is for when you want to override a method... to create maybe an improved version of a class that could be used as the replacement for the old class. Also, we should only inherit from classes that were created with the purpose of being inherited.

Like

Unhelpful
Jaroslaw Zelinski

Principal Consultant, Business Software & Systems Designer. #MBSE #MDE expert using #UML #BPMN #SysML
Report contribution
This is the basic principle of distinguishing conceptual models with generalization from component models and their components. Transferring generalization structures to the application architecture is very harmful: it causes making even small changes in the future requires interfering with the entire inheritance structure.

Like

Unhelpful

5 Choosing the right level of inheritance

When deciding how many levels of inheritance to use for your classes, there is no definitive answer as it depends on the context and the design goals of your project. However, some general guidelines can help you decide the right level of inheritance. Firstly, inheritance should only be used when there is a clear and logical “is-a” relationship between the classes. Additionally, the subclasses should share common attributes and methods that are relevant and meaningful to them. Furthermore, the subclasses should respect the Liskov substitution principle and not violate or alter the behavior or contract of the superclass. Lastly, composition should be used over inheritance when classes have a “has-a” or “can-do” relationship, or when higher cohesion, lower coupling, and greater modularity are desired. By following these guidelines, you can choose an appropriate level of inheritance that will result in a more robust and maintainable object oriented design.

Add your perspective

Paulo Zemek

Software Engineer - I talk to computers and they understand me even without AI, we just speak the same language
Report contribution
The "is-a" relationship ends-up becoming a bad "translation" as every square "is-a" rectangle by simple definition, yet that doesn't work when programming with mutable objects. When talking about programming, we should only inherit a class if we have a real reason to... and this usually means we need to override a method, or our class needs to inherit from another class only to be used by a framework (but then I would argue it is a bad framework to force that to happen). That is... ignore any logic like an "is-a" as that will probably cause more confusion than solve problems, and just focus on "do I need to override any method of this class?" if the answer is no, then don't create a sub-class. Simple as that.

Like

Unhelpful

6 Here’s what else to consider

This is a space to share examples, stories, or insights that don’t fit into any of the previous sections. What else would you like to add?

Add your perspective

Object Oriented Design

Rate this article

We created this article with the help of AI. What do you think of it?

It’s great It’s not so great

Report this article

See all

How do you choose the right level of inheritance for your classes?

1

2

3

4

5

6

1 Benefits of inheritance

2 Drawbacks of inheritance

3 Liskov substitution principle

4 Composition over inheritance

5 Choosing the right level of inheritance

6 Here’s what else to consider

Object Oriented Design

Rate this article

Thanks for your feedback

More articles on Object Oriented Design

More relevant reading