5.14 Using Inheritance to Hide the Representation of a Class

Recall our Dictionary class from Chapter 2's (Section 2.3) discussion on class cohesion and coupling. In that example, we took a dictionary that contained a property list and hash table with the four operations hadd , padd , hfind , and pfind and converted it into two classes called PDictionary and HDictionary , each having "add" and "find" operations. This solution eliminated the weak coupling and non-communicating behavior found in the Dictionary class but required the builder of Dictionary objects to decide which implementation of dictionaries he or she wanted. In some domains, leaving this decision to the users is appropriate. If the builder of a dictionary understands how he or she will use the dictionary, then perhaps he or she should be the one to make the implementation decision. Some may object to my concatenating the name of a data type to the word "dictionary," but that is just an argument of class naming. If we called them SmallDictionary and LargeDictionary , most objectors would disappear.

(Side note: I am constantly surprised at the amount of time wasted during design critiques when two parties think they are arguing about some important design issue when, in fact, they are arguing only about the name of a class. Some of these discussions are due to the learning curve, and some are intrinsic to design in general. I think I have become faster at catching these cases, but I am amazed at how often I get dragged into such discussions. I am tempted to add this tongue-in-cheek heuristic: "If two parties who know what they are talking about argue for a long period of time during a design critique, flip a coin to resolve the situation." The argument implies that the two camps are in a design situation where there does not exist a clear trade-off between the two contested designs. The "who know what they are talking about" clause is very important. Sometimes critique arguments go on for a long period of time because neither party knows what they are talking about. I do not mind arguing for six hours over the name of a class as long as I understand that, at the end of the argument, all I stand to win or lose is a class name.)

In many domains it is not appropriate for the users of a class to decide a class's representation. The class implementors are expected to decide the best representation for the class, based on its current state. Whenever the state changes, the class implementors are required to examine the change and determine if the representation still adequately reflects the best solution for the given use of the object. If the representation becomes inappropriate, the implementors are expected to effect the necessary representational changes. In the case of dictionaries, the constraints may state that for dictionaries with less than 100 words, property lists are the best representation; for dictionaries with more than 100 words, hash tables become more appropriate. When a Dictionary object's user adds the 100th word to the object, the Dictionary class automatically changes its representation from a property list to a hash table. If a Dictionary object's word count drops below 100, the Dictionary class will change the representation back to a property list from the hash table. This change of representation is completely hidden from the users of the class (see Figure 5.31).

Figure 5.31. Dictionary with hidden, changing representation.