Separate the construction of a complex object from its representation so that the same construction process can create different representations.
A reader for the RTF (Rich Text Format) document exchange format should be able to convert RTF to many text formats. The reader might convert RTF documents into plain ASCII text or into a text widget that can be edited interactively. The problem, however, is that the number of possible conversions is open-ended. So it should be easy to add a new conversion without modifying the reader.
A solution is to configure the RTFReader class with a TextConverter object that converts RTF to another textual representation. As the RTFReader parses the RTF document, it uses the TextConverter to perform the conversion. Whenever the RTFReader recognizes an RTF token (either plain text or an RTF control word), it issues a request to the TextConverter to convert the token. TextConverter objects are responsible both for performing the data conversion and for representing the token in a particular format.
Subclasses of TextConverter specialize in different conversions and formats. For example, an ASCIIConverter ignores requests to convert anything except plain text. A TeXConverter, on the other hand, will implement operations for all requests in order to produce a TeX representation that captures all the stylistic information in the text. A TextWidgetConverter will produce a complex user interface object that lets the user see and edit the text.
Each kind of converter class takes the mechanism for creating and assembling a complex object and puts it behind an abstract interface. The converter is separate from the reader, which is responsible for parsing an RTF document.
The Builder pattern captures all these relationships. Each converter class is called a builder in the pattern, and the reader is called the director. Applied to this example, the Builder pattern separates the algorithm for interpreting a textual format (that is, the parser for RTF documents) from how a converted format gets created and represented. This lets us reuse the RTFReader's parsing algorithm to create different text representations from RTF documentsójust configure the RTFReader with different subclasses of TextConverter.
The next step is to translate the domain definitions into a number of Elisa components.
Based on the domain definitions a set of related components can be derived.
The first domain definition is a selection domain. It specifies a number of alternative domains. The implementation of selection domains is based on the concepts of categories. The following component implements the TextConverter = ASCIIConverter | TeXConverter | TextWidgetConverter.
The definitions in this component use patterns for dynamic type matching to select the definition rule which corresponds to the matching type. For example, the first definition rule of the Scrollbar definition test first if the type of the WidgetFactory argument is of the MotifWidgetFactory type. If that is the case, the corresponding Scrollbar function will be executed. Otherwise the following definition rule will be tried.
The second domain definition, ASCIIConverter = Character + Text, is simpler. It specifies the interfaces to the ASCIIConverter.
The component of the third domain definition, TeXConverter = Character + Font + Paragraph + Text,is similar to the implementation of the second domain definition. It specifies the interfaces to the TeX conversion functions. The actual implementation depends on those TeX conversion functions.
The component of the fourth domain definition, TextWidgetConverter = Character + Font + Paragraph + Text,is similar to the implementation of the domain definition for TeXConverters.
This page was last modified on 13-11-2012 15:57:59