Feeds

Code inheritance and reuse: a delicate balancing act

The pot of gold at the end of many rainbows

Internet Security Threat Report 2014

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:

  • Use composition and inheritance to promote reuse. Do not focus on one approach while ignoring the other.
  • Attempt to minimise dependency between subclass and superclass (don't access variables etc.).
  • Use the following guidelines for subclassing:
    1. If methods that are inherited from the superclass can violate the integrity of the subclass, use composition rather than inheritance.
    2. When overriding methods, don't change their original purpose.
    3. Remember that the subclass itself can be extended, and consider the interface that it presents to its potential subclasses (from both itself and its parent).
  • Look for situations that are appropriate for "design for pluggable extension" rather than "method" extension; as exemplified by JPanel in Java. The way in which it lays out the graphic components it displays is dependent on the behaviour of a layout manager, which is an object that is plugged into the panel. It alters the way that the graphics components operate without the need to subclass.
  • Attempt to provide structural classes in which the function can be provided by subclasses (or plug in objects) when creating a root superclass. Complete structural, but non-functional, classes are ideal for inheritance and can provide the entire infrastructure required for a specific type of behaviour. The user then specifies his/her own extensions that fit into (but do not alter) that infrastructure. For example, the JApplet class provides a powerful, and complex to implement, framework within which a developer can implement his/her own functionality (e.g. the methods init(), start(), stop(), suspend() etc. without the developer ever needing to know how that framework operates (or how to modify it).
  • Provide structural classes with gaps for functional classes (e.g. the class Thread with Runnables in Java).

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. ®

Security for virtualized datacentres

More from The Register

next story
Microsoft WINDOWS 10: Seven ATE Nine. Or Eight did really
Windows NEIN skipped, tech preview due out on Wednesday
Business is back, baby! Hasta la VISTA, Win 8... Oh, yeah, Windows 9
Forget touchscreen millennials, Microsoft goes for mouse crowd
Apple: SO sorry for the iOS 8.0.1 UPDATE BUNGLE HORROR
Apple kills 'upgrade'. Hey, Microsoft. You sure you want to be like these guys?
ARM gives Internet of Things a piece of its mind – the Cortex-M7
32-bit core packs some DSP for VIP IoT CPU LOL
Microsoft on the Threshold of a new name for Windows next week
Rebranded OS reportedly set to be flung open by Redmond
Lotus Notes inventor Ozzie invents app to talk to people on your phone
Imagine that. Startup floats with voice collab app for Win iPhone
'Google is NOT the gatekeeper to the web, as some claim'
Plus: 'Pretty sure iOS 8.0.2 will just turn the iPhone into a fax machine'
prev story

Whitepapers

Forging a new future with identity relationship management
Learn about ForgeRock's next generation IRM platform and how it is designed to empower CEOS's and enterprises to engage with consumers.
Storage capacity and performance optimization at Mizuno USA
Mizuno USA turn to Tegile storage technology to solve both their SAN and backup issues.
The next step in data security
With recent increased privacy concerns and computers becoming more powerful, the chance of hackers being able to crack smaller-sized RSA keys increases.
Security for virtualized datacentres
Legacy security solutions are inefficient due to the architectural differences between physical and virtual environments.
A strategic approach to identity relationship management
ForgeRock commissioned Forrester to evaluate companies’ IAM practices and requirements when it comes to customer-facing scenarios versus employee-facing ones.