Design Patterns : Elements of Reusable Object-Oriented Software

Encapsulating the Analysis 
From all indications, we need to encapsulate the analysis in aseparate object, 
much like we've done many times before. We could putthe machinery for a given 
analysis into its own class. We could usean instance of this class in conjunction 
with an appropriate iterator.The iterator would "carry" the instance to each glyph 
in thestructure. The analysis object could then perform a piece of theanalysis 
at each point in the traversal. The analyzer accumulatesinformation of interest 
(characters in this case) as the traversalproceeds: 

---

Design Patterns: Elements of Reusable Object-Oriented Software 
85 
The fundamental question with this approach is how the analysis 
objectdistinguishes different kinds of glyphs without resorting to typetests or 
downcasts. We don't want a SpellingChecker classto include (pseudo)code like 
void SpellingChecker::Check (Glyph* glyph) { 
Character* c; 
Row* r; 
Image* i; 
if (c = dynamic_cast(glyph)) { 
// analyze the character 
} else if (r = dynamic_cast(glyph)) { 
// prepare to analyze r's children 
} else if (i = dynamic_cast(glyph)) { 
// do nothing 
} 
} 
This code is pretty ugly. It relies on fairly esoteric capabilitieslike type-safe 
casts. It's hard to extend as well. We'll have toremember to change the body of 
this function whenever we change theGlyph class hierarchy. In fact, this is the 
kind of code thatobject-oriented languages were intended to eliminate. 
We want to avoid such a brute-force approach, but how? Let's considerwhat happens 
when we add the following abstract operation to the Glyphclass: 
void CheckMe(SpellingChecker&) 
We define CheckMe in every Glyph subclass as follows: 

---