Design Patterns : Elements of Reusable Object-Oriented Software

Composite Pattern 
Recursive composition is good for more than just documents. We can useit to 
represent any potentially complex, hierarchical structure. TheComposite (183) 
pattern captures the essence ofrecursive composition in object-oriented terms. 
Now would be a goodtime to turn to that pattern and study it, referring back to 
thisscenario as needed. 

---

Design Patterns: Elements of Reusable Object-Oriented Software 
53 
Formatting 
We've settled on a way to 
represent
the document's physicalstructure. Next, we 
need to figure out how to construct a 
particular
physical structure, one that 
corresponds to a properlyformatted document. Representation and formatting are 
distinct: Theability to capture the document's physical structure doesn't tell 
ushow to arrive at a particular structure. This responsibility restsmostly on 
Lexi. It must break text into lines, lines into columns,and so on, taking into 
account the user's higher-level desires. Forexample, the user might want to vary 
margin widths, indentation, andtabulation; single or double space; and probably 
many other formattingconstraints.
6
Lexi'sformatting algorithm must take all of 
these into account. 
By the way, we'll restrict "formatting" to mean breaking a collection ofglyphs 
into lines. In fact, we'll use the terms "formatting" and"linebreaking" 
interchangeably. The techniques we'll discuss applyequally well to breaking lines 
into columns and to breaking columns intopages. 
Encapsulating the Formatting Algorithm 
The formatting process, with all its constraints and details, isn't easy toautomate. 
There are many approaches to the problem, and people have come upwith a variety 
of formatting algorithms with different strengths andweaknesses. Because Lexi 
is a WYSIWYG editor, an important trade-off toconsider is the balance between 
formatting quality and formatting speed. Wewant generally good response from the 
editor without sacrificing how goodthe document looks. This trade-off is subject 
to many factors, not all ofwhich can be ascertained at compile-time. For example, 
the user mighttolerate slightly slower response in exchange for better formatting. 
Thattrade-off might make an entirely different formatting algorithm 
moreappropriate than the current one. Another, more 
implementation-driventrade-off balances formatting speed and storage 
requirements: It may bepossible to decrease formatting time by caching more 
information. 
Because formatting algorithms tend to be complex, it's also desirableto keep them 
well-contained or
—
better yet
—
completely independentof the document structure. 
Ideally we could add a new kind of Glyphsubclass without regard to the formatting 
algorithm. Conversely,adding a new formatting algorithm shouldn't require 
modifying existingglyphs. 
These characteristics suggest we should design Lexi so that it'seasy to change 
the formatting algorithm at least at compile-time, ifnot at run-time as well. 
We can isolate the algorithm and make iteasily replaceable at the same time by 

---