Original URL: http://www.theregister.co.uk/2006/07/27/inheritance_reuse/

Code inheritance and reuse: a delicate balancing act

The pot of gold at the end of many rainbows

By John Hunt

Posted in Developer, 27th July 2006 12:08 GMT

There are two primary concepts that are used extensively within Java (and indeed other OO languages) to promote reuse - inheritance and componentisation.

For many people, inheritance is the obvious (and classic) example of how to achieve reuse within Java systems. However, the ability to plug components together is equally important. Here a component can be anything from a class that implements an interface and is "plugged together" with a class that uses the protocol defined by the interface to JavaBeans; to much larger components such as a JMS system, or transaction management system. The key is that the component is used as is, without any modification.

Typically, within the literature on languages such as Java, the focus is often on inheritance (particularly in tutorial or training/educational materials). However, in practice, the reuse of components can be equally (if not more) important.

One way to distinguish between inheritance-based reuse and compositional reuse is that inheritance-based reuse is primarily developer-oriented ("developer" here refers to those developing the functionality of the elements which might comprise a component); while compositional reuse is user-oriented (that is, no further development of the component takes place).

In the following we will briefly look at inheritance oriented reuse (and its role) and component based reuse.

Inheritance-oriented reuse

Below we consider how classes can be modified through inheritance, and the dangers associated with this. Then, we propose the use of composition to promote reuse in some situations.

Categories of extension

When inheritance is used, an existing class (the superclass) is extended to create a new class (the subclass). The way in which it is extended can be categorised as modifications to the external protocol of the superclass; or as changes to the behaviour (implementation) of methods. These two categories are considered in more detail below.

Changes to the external protocol

When a subclass adds new methods that are available outside the class, it changes the external protocol of the superclass. This happens in a number of different situations:

Changes in the implementation of the methods

If a subclass overrides a superclass's methods, then it modifies the behaviour of the superclass. Again, there are a number of different situations within which this can happen:

Compositional reuse

By compositional reuse, I mean the "combination of independent components into larger units". These components can be combined together in different ways, as long as their interfaces are compatible (in a similar manner to a jigsaw puzzle). In general, no further development for the components themselves takes place. Instead, a user of a component is allowed to customise the behaviour of a component via predefined properties or methods.

Strengths of compositional reuse

As we all know, software components designed for compositional reuse have great potential. They can greatly improve a developer's productivity and the reliability of software. A key aspect of this is the "low software dependency" between the component and the software using that component. That is, when a developer uses a software component, the only dependency between his/her code and the component is the component's interface. Particularly if the software is a commercial component, the developer cannot get inside the encapsulation bubble.

There is therefore no dependency between their code and the internals of the component (i.e. its structure or internal state). This is very significant. It means that, as long as the interface to the component remains the same, the programmer should experience no problems using the component, even if its internals are completely rewritten.

Weaknesses of compositional reuse

The weakness of the compositional approach is that it is essentially a "take it or leave it" approach. That is, you get just what you see and are not allowed to change the internals of the component. By contrast, inheritance obviously allows for far greater flexibility.

Without inheritance, but with compositional reuse, a developer would end up with a great deal of duplication of code in situations where similar (but slightly different) behaviour to that which already exists is needed. And, of course, by duplicating code s/he would be introducing "implicit" dependency between the duplicated pieces of code...That is, if a bug were found in one piece of code that had been duplicated, it would be necessary to find all the duplicated pieces of code and to correct that bug individually in each. Not only is this a tedious task, it is also error-prone.

Promoting reuse in object oriented systems

It is worth considering the idea that neither an approach based purely on compositional reuse, nor one based on inheritance alone, is likely to be sufficient. In fact, I have found that using both techniques together can provide the greatest advantage. To help with this I have formulated some general guidelines which are actually relatively easy to identify:

Finally, remember that re-use, like quality, is only free if you are prepared to pay for it. Reuse doesn't just happen. You need to design for reuse and accept that this may increase costs slightly on the first project – then you will be repaid many times on subsequent projects. ®