Design Patterns : Elements of Reusable Object-Oriented Software

Design Patterns: Elements of Reusable Object-Oriented Software 
54 
encapsulating it in an object.More specifically, we'll define a separate class 
hierarchy for objectsthat encapsulate formatting algorithms. The root of the 
hierarchy willdefine an interface that supports a wide range of 
formattingalgorithms, and each subclass will implement the interface to carryout 
a particular algorithm. Then we can introduce a Glyph subclassthat will structure 
its children automatically using a given algorithmobject. 
Compositor and Composition 
We'll define a 
Compositor
class for objectsthat can encapsulate a formatting 
algorithm. The interface (Table 2.2) letsthe compositor know 
what
glyphs to format 
and 
when
to do the formatting. The glyphs it formats are the children ofa special 
Glyph subclass called 
Composition
. Acomposition gets an instance of a Compositor 
subclass (specializedfor a particular linebreaking algorithm) when it is created, 
andit tells the compositor to Compose its glyphs whennecessary, for example, when 
the user changes a document.Figure 2.5 depicts the relationships between the 
Composition and Compositor classes. 
Responsibility
 
Operations
 
what to format
void SetComposition(Composition*) 
when to format
virtual void 
Compose()
Table 2.2 Basic compositor interface 
Figure 2.5: Composition and Compositor class relationships 
An unformatted Composition object contains only the visibleglyphs that make up 
the document's basic content. It doesn't containglyphs that determine the 

---

Design Patterns: Elements of Reusable Object-Oriented Software 
55 
document's physical structure, such asRow and Column. The composition is in this 
state just after it'screated and initialized with the glyphs it should format. 
Whenthe composition needs formatting, it calls its compositor'sCompose operation. 
The compositor in turn iteratesthrough the composition's children and inserts 
new Row and Columnglyphs according to its linebreaking algorithm.
7
Figure 2.6 shows 
the resulting objectstructure. Glyphs that the compositor created and inserted 
intothe object structure appear with gray backgrounds in the figure. 
Figure 2.6: Object structure reflectingcompositor-directed linebreaking 
Each Compositor subclass can implement a different linebreaking algorithm.For 
example, a SimpleCompositor might do a quick pass without regard forsuch esoterica 
as the document's "color." Good color means having an evendistribution of text 
and whitespace. A TeXCompositor would implement thefull TeX algorithm [Knu84], 
which takes things like color into accountin exchange for longer formatting times. 
The Compositor-Composition class split ensures a strong separationbetween code 
that supports the document's physical structure and thecode for different 
formatting algorithms. We can add new Compositorsubclasses without touching the 
glyph classes, and vice versa. Infact, we can change the linebreaking algorithm 
at run-time by adding asingle SetCompositor operation to Composition's basic 
glyphinterface.