Chapter:Inheritance - Problems with inheritance

From Juneday education
Jump to: navigation, search

Meta information about this chapter

Expand using link to the right to see the full content.


The purpose of this lecture is to shed some light on the potential problems of using inheritance, to show the students that inheritance isn't a silver bullet, and that it can actually introduce new problems when we were using it to solve others.

We believe, additionally, that showing students that they can inherit a class like JFrame in order to get direct access to some inherited instance methods leads to a poor understanding of what inheritance is meant to be. Not only do we convey a poor use case for inheritance, we also miss an opportunity to show and discuss composition.

In Java, you can only extend one class at the time. This means that you should think carefully when to use inheritance. The choice to extend a class should be well motivated and thought-through.


After this lecture, we want the students to beware of the following:

  • Using inheritance to save code and get access to some methods often isn't the right motivation for using inheritance
    • Extending JFrame when you are not creating a new, specialized for of JFrame can lead to overriding methods "by mistake"
    • Extending JFrame just to save some typing, does indeed create a new type of JFrame which is probably not what you meant
    • Extending JFrame just to save some typing, means we cannot inherit anything else
    • Extending JFrame to get direct access to a few methods we are using (like add(), pack(), setSize() etc) means that we are using a few percent of all the methods we inherit - which seems like overkill
  • Inheriting a class from an API makes us depending on that the API doesn't change
    • what happens if a future version of the API class adds a method which we already have implemented? If we are unlucky, our own method now overrides a new method in the API class (unlikely but can happen)
  • If subclasses differ very little from subclasses, then we risk ending up with a lot of boilerplate code which actually means writing the same code over and over, rather than re-using code
  • Inheritance in Java allows only one explicit super class
    • what if an object needs to be of two types which are siblings or cousins?
    • Typical example is to have Employee as super class and many specialized employee classes as subclasses - what if an employee is both a Manager and an Engineer? We can't be both if they are siblings or cousins!
    • What if the application needs to allow a new type of employee - we need to write a new class to meet this new situation
  • There are alternatives to inheritance
    • Composition - e.g. A class can have a JFrame
    • Using roles - e.g. an employee can have one to many roles allowing an employee to have both the role "manager" and the role "engineer"
    • There are other techniques and design patterns available for those who want to learn more, like the strategy pattern, etc
  • Making vital parts of a class (in an API you are writing) protected forces clients to extend your class in order to use it
  • You don't have to use protected whenever you design a class to allow inheritance
    • protected is more "open" than private and package private
    • if you agree that information hiding is a good thing, you should consider carefully whether to use private or protected access for members of a class
    • Some people go as far as to say that protected access defies the principle of information hiding and should not be used - students are welcome to make their own opinion about this, but it is probably interesting to know that strong opinions on inheritance (and many other things) exist
  • That designing classes and relationships between classes, is about finding abstractions
    • We should make an effort to find the right level of abstraction, e.g. do we need many levels of abstractions?
    • Abstractions are about simplification and manageability of complex things
      • We don't plan for taking a blue metallic 2008 Saab 95 combustion engine propelled car whose driver works for a people transportation company, when planning our ride from the airport - We consider a taxi (or maybe an Uber, or even a Snapp if you are in Iran)

Instructions to the teacher

Common problems related to this chapter

  • Discussing the use of protected is a complicated matter - in our course material we have decided to consider protected to be an advanced topic which could be outside the scope for examination when our material is used as course litterature
    • Students should know about protected on a syntactical and semantic level, but not necessarily from a design point of view
  • Students may wonder when to use inheritance, if it is so complicated and error prone
    • Our answer is to look at APIs for inspiration of good uses of inheritance for inspiration
    • Another answer we have, is to be upfront about the fact that designing a class for inheritance is rather hard and that includes choosing access level

Inheritance: Problems with inheritance

Some points to think about:

  • Inherit because of laziness
    • Inheriting the wrong class, is your class really and foremost an extension of the superclass?
    • Example: Inherit JFrame to reduce code
    • Warning sign: "If I inherit this class I get some stuff for free"
    • Use the "Is a" test, is your subclass really a <Superclass> or could it just as well have an instance of the superclass as a component?
  • Do we really reduce the amount of code
  • Employee, Manager, Developer, Project Manager, etc. What about if we have two roles? Does it reduce the amount of code if we use inheritance? What is it we gain....apart from satisfying someone's idea of a good design?
  • Inheritance breaks information hiding - particularly using protected
  • Inheritance can change the semantics of the super class
    • Example: If Square is a subclass to Rectangle - what happens when we change the side of a rectangle and it happens to be a square? Can we use squares everywhere where we need a rectangle? Etc.

Using inheritance, when used improperly, causes lot of problems. This chapter's video lecture shows some of the problems with inheritance.

Chapters on the topic of Inheritance

You are now done (after the exercises at least) with all the chapters on Inheritance. Great job! Keep it up!


Note: To date (2018-10-23), there is only one video in English, and one video in Swedish. More may be added later.

English videos

Swedish videos


Further reading

Where to go next

Next page has exercises for this chapter: Inheritance_-_Problems_with_inheritance_-_Exercises

« PreviousBook TOCNext »