|
|
|
|
|
|
|
If you want a rooted hierarchy, you'll want to give the root class a fairly generic name (like pObject) and few capabilities. The point of a root object is to be able to create collections of all its descendants and refer to them as instances of pObject. The trade-off is that rooted hierarchies often percolate interface up into the root class. |
|
|
|
|
|
|
|
|
The next likely candidates for top-of-the-hierarchy status are pStored and pWired. pStored objects are saved to disk at various times (for example, when the program is not in use), and pWired objects are sent over the modem or network. Because nearly all your objects will need to be stored to disk, it makes sense to push this functionality up high in the hierarchy. Because all the objects that are sent over the modem must be stored, but not all stored objects must be sent over the wire, it makes sense to derive pWired from pStored. |
|
|
|
|
|
|
|
|
Each derived class acquires all the knowledge (data) and functionality (methods) of its base class, and each should have one discrete additional capability. Thus pWired may add various methods, but all of these methods are designed to facilitate transfer of data over a modem. |
|
|
|
|
|
|
|
|
It is possible that all wired objects are stored, or that all stored objects are wired, or that neither of those statements is true. If only some wired objects are stored, and only some stored objects are wired, you will be forced either to use multiple inheritance or to hack around the problem. A potential hack for such a situation would be to inherit, for example, Wired from Stored, and then to make the stored methods do nothing or return an error for those objects that are sent via modem but are never stored. |
|
|
|
|
|
|
|
|
In fact, you realize that some stored objects clearly are not wired; for example, user preferences. All wired objects, however, are stored, so your inheritance hierarchy so far is as reflected in Figure 22.1. |
|
|
|
|
|
|
|
|
FIGURE 22.1
Initial inheritance hierarchy. |
|
|
|
|
|
