Chapter 3

Object Oriented Interfaces

Object oriented design is a large topic with many encyclopedic tomes dedicated 

to it. This section will give you an introduction to some of the more useful techniques 

that you can use to improve your OO module design.

Inheritance or Composition

Determining when and how to use inheritance is perhaps the hardest job in 

object oriented interface design. Inheritance is a powerful tool it can open up 

new avenues of extensibility for your users and allow you to reduce code size by 

exploiting polymorphism. On the other hand, inheritance can serve to greatly 

increase the complexity of otherwise simple designs.

The classic rule is deceptively simple inheritance relationships should be 

used when classes exhibit an  is a  relationship. This is easy to demonstrate using 

real world classes, Shape and Square being the usual examples. Since an object of 

the Square class  is a  Shape, inheritance is the right choice. Shape will naturally 

provide an area() method, and Square can inherit from Shape and provide an 

implementation of area() that uses Square's height and width attributes.

However, in the real world things tend to be a less clear cut. Often there's no 

independent standard to judge whether an  is a  relationship applies. Does your 

brand new CGI::MailForm class enjoy an  is a  relationship with the CGI module? 

That's hard to know it could or maybe it just  has a  CGI object. The latter possi 

bility is known as composition, and the classic rule is that the classes in question 

should share a  has a  relationship.

The principal difference between inheritance and composition is the degree 

of coupling between the classes involved. Using inheritance, the objects are the 

same they share the same underlying data structure. As a practical matter, this 

means that the child class needs to know intimate details about the implemen 

tation of the parent class: Does it use a hash underneath, what convention can be 

used to stake out a private namespace within the object, and so on. If the parent 

class changes its implementation, it could break child classes.

Composition, on the other hand, is a loose coupling. The two classes remain 

distinct, and their objects do not share the same underlying data structure. This 

loose coupling can also be exposed to the user by allowing the user to initialize the 

contained object directly. This is a powerful technique since it lets users access 

methods in the contained object without requiring an inheritance relationship. 

That said, composition usually requires more code to implement.

Classes using composition can approximate some of the advantages of inher 

itance by proxying calls to contained objects. This means that the class sets up a 

method that passes calls through to an equivalent method of a contained object. 

82