Inheritance

So far most people would say that objects are a great idea – they provide a way to package subroutines with data and they offer many benefits with few downsides. However, this is not the case with the object-oriented method’s biggest proclaimed advantage, code reuse via inheritance.

Suppose you have an implementation of a Person object complete with all the data fields and methods that are required. Now suppose that you want to add a Customer object to your program – how can you do this? You could start from scratch and write the instructions for your new object, but you already have a Person object and surely a Customer is a Person? There should be some way of using the Person object to create a Customer object.

The most direct way, and the one in use since almost the start of programming, is copy-and-paste reuse. You simply take the instructions that make up the Person object and copy and paste them to a new part of the program and make the changes and additions needed to create the Customer object, maybe by adding a field for a customer number. Copy-and-paste reuse is simple, but it actually copies instructions and if you find a bug in Person you have to remember to correct it in Customer and any other objects that you derived from Person. This leads to the belief that there should be a better way.

Currently that better way is generally accepted to be “inheritance”. You can create a new class and specify that it should inherit everything that another class has. The class that inherits is called a “derived” or “child” class and the inherited class is the “base” or “parent” class. The derived class has all of the properties and methods of the base class. If this was all there was to inheritance it would be useless because the derived class would be identical to the base class. What makes it useful is that, like copy-and-paste reuse, you can add properties and methods to the derived class. What this means is that you can extend the derived class to create new behavior. For example, the Customer class derived from Person can have a customer number field added together with any methods that work with that field that are needed.

Extending derived classes in this way isn’t controversial and it isn’t very dangerous. If you find a bug in the Person class then you can correct it and expect any derived class to be updated to be correct without you having to do anything extra about it. Inheritance is dynamic and changes to the base class are automatically passed on to the derived classes.

This is good, but there is a risk that the new methods in the derived class will be broken by changes to the way the base class works. For example, suppose the Customer class constructed a customer number using the Age field in the Person class and the way that this was recorded was changed from a number to a string. This change might not cause any problems for the base class because it doesn’t do anything with the Age field, but the derived class would surely be broken by the change. To stop this happening the encapsulation principle is extended from just the external world to the derived class. That is, as far as the derived class is concerned the base class is a black box and it cannot access its internal workings. This is easy to say, but very difficult to implement. Different languages provide different ways of isolating the internals of the base class from the derived class. The stronger the isolation the less useful the base class is to the derived class as derived classes usually want to access the internal workings to extend what the base class does!

Overriding

Things get even worse when you allow the derived class to modify what the base class does. Most languages allow the programmer to redefine anything inherited from the base class. Usually this involves writing new versions of inherited methods called “overriding” methods. The inherited methods that are replaced by the overriding methods are said to be overridden.

The overriding methods are used in the derived class in place of the inherited, overridden method – the overriding method replaces the inherited method.

If an overridden method is corrected in the base class then it is clear that this change isn’t going to be passed on to the derived class. Thus, overridden methods break the connection to the base class. What is worse, the overriding method may do things in a completely different way to the base class and this may make any changes to the base class less compatible with the derived class.

Put simply, overriding inherited methods isn’t a safe thing to do and different language impose restrictions and mechanisms to make it safer. In many you can’t override an inherited method unless you state clearly that this is what you are doing.

In chapter but not in this extract

• Real World Objects
• Inheritance Hierarchies
• The Liskov Problem
• Restrictions
• Why are Objects So Unreasonably Effective?

Summary

• Object-Programming OPP is currently the most used programming methodology. It works by simply associating subroutines with the data they work with. Put simply, an object is a struct with fields that are subroutines or methods.

• We also need a way to create multiple copies of objects and this leads to the idea of a class. A class defines an object and allows the programmer to create as many instances of the object as needed.

• The first advantage of using classes and objects is polymorphism which ensures that the correct method will be called depending on the object in use.

• The second advantage of using classes and objects is encapsulation, which means that the workings of the object can be hidden from the outside world.

• The third advantage of using classes and objects, inheritance, isn’t always seen as an advantage. This is a way of reusing existing objects to create new extended objects.

• Inheritance is dynamic and any changes made to a base class are passed on to derived classes. Inherited methods can be redefined or overridden and this is the cause of many problems.

• The philosophy of object-oriented programming uses the idea that objects are simulations of the real world and inheritance mirrors the relationships between objects in the real world.

• The Liskov principle states that a derived class can be used in place of a base class. This is only true if you work at making it true. Overriding can cause derived classes not to function as substitute base classes.

• The usual real world relationship modeled by inheritance is IS A but many other relationships are possible. In particular, the HAS A relationship leads to the idea of containment.

• Despite all of the subtle problems with object-oriented programming, it is hugely successful. The reason is that consuming objects is much easier than creating or modifying them and this is what most programmers do.

• My advice to the beginning programmer is to focus first on the flow of control and top-down structured programming before object, an approach that is fostered by Python.

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info