2.4. Splitters Versus Lumpers

 <  Day Day Up  >  

If the world were perfect, you would have exactly one unique name for each concept in a system. In this imperfect world, having two concepts with the same name leads to confusion. In Sam's case, the term CD was applied to both a CDRelease and a CDDisc. Separating the two concepts with two names clarified the requirements.

Using two different names for a single idea can also be confusing, albeit less so than two ideas with a single name. Referring to a physical CD as both a CDDisc and a CDPhysical might be justified by political measures. ("This department calls it this and that department calls it that.") Sam referred to the act of renting a CD as both renting a CD and checking out a CD. If these two terms really encompass the same operation, the duality of reference can be annoying, but might not be confusing.

Sometimes it is hard to determine whether you have two independent concepts or one. Try making up a one-line definition for a name. If it is difficult to create a simple definition, go ahead and use two names. Later on, if you find that the distinction was meaningless, you can always declare the two names to be synonyms. Suppose that Sam and I came up with the terms CDAlbum and CDRelease . We might distinguish them by stating that a CDAlbum is a collection of songs with a title given to the set, and a CDRelease is a collection of songs that was released on a single CDDisc.

The conversion from one style of architecture, design, or coding to another is not necessarily symmetrical. Suppose that a single name has been used to denote two ideas. Later you decide that you need to replace that name with appropriate names for each idea. You need to examine each usage of the term carefully to determine which of the two concepts it represents. On the other hand, suppose that you have used two different names for a single concept. If you want to combine those into a single name, you can do a simple global replacement.

For example, suppose we have a class called Message , which represents messages displayed to the user . We think at the beginning that these messages are going to behave differently, so we divide them into WarningMessage s, ErrorMessage s, SevereErrorMessage s, and ReallySevereErrorMessage s. We make every message an object of one of these four classes. Later on, we realize that SevereErrorMessage s and ReallySevereErrorMessage s really do not behave differently. We can eliminate the distinction using a simple search and replace. Conversely, if we had not distinguished the two and later found that there should be a difference, we would have to look closely at each object of SevereErrorMessage to determine whether it should be categorized as ReallySevereErrorMessage .

SPLITTERS CAN BE LUMPED MORE EASILY THAN LUMPERS CAN BE SPLIT

It is easier to combine two concepts than it is to separate them.


 <  Day Day Up  >  


Prefactoring
Prefactoring: Extreme Abstraction, Extreme Separation, Extreme Readability
ISBN: 0596008740
EAN: 2147483647
Year: 2005
Pages: 175
Authors: Ken Pugh

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net