Roxanne,

Good post!

It is true that inheritance is probably the single most overused feature of OO. While it is a necessary feature it is not the highest in terms of real reusability. One of the reasons for this is that inheritance requries a white box approach to class design. White box means that in order to specialize a class through subclassing it is necessary to now details about the the parent class's imlementation.

It is not possible to specialize a method in a sub-class if you have absolutely no knowledge of the parent class's implementation. You must determine when, in the sub-class, to call the parent class code. That means you must nknow what that code is doing and what effect it will have on your sub-class's code.

A stronger and more versatile approach is to use a strategy pattern in constructing the class. As an example, let's consider a data object that can save data to the source. We create a class named DataMgr and give it a savedata method. Now we need a LocalDataMgr to save local data and a remotedatamgr to save remote data. Probably also need an ADODataMgr to deal with ADO record sets and an XMLDataMgr to deal with XML.

An alternate design would be to build the DataMgr class so it has a property named DataAccessClass which contains the name of the class to be used for dataacess. Now we create mulitple dataaccess classes, one for each of the above situations, LocalDA, RemoteDA, ADODA, etc. In the Init of the dataMgr we do an addobject of the data access object that the DataAccessClass points to. The datamgr exposes methods to the outside world and simply delegates, internally, to its Dataaccess object.

So where's the benefit? Simple, a new data source requires that we create a new dataaccess class for it, there is no need to change anything anywhere else. The dataaccess class has to expose the same interface to the datamgr but the actual implemntation code is irrelevant to the proper functioning of the composit. The new dataaccess class does not need to know anything about the datamgr other than the interface it must expose. We can modify the behavior of the datamgr without creating subclasses of the datamgr. Inheritance becomes a non-issue in this design.