CSC/ECE 517 Fall 2012/ch2b 2w35 av

Introduction

One of the most complex tasks in creating a software is designing it to meet the needs of the user. Designing an object-oriented components of software that is reusable is hard. One must find pertinent objects, factor them into classes at the right granularity, define class interfaces and inheritance hierarchies, and establish key relationships among them. It should also be taken care that the design is specific to a problem at hand and also general enough to accommodate future changes. Knowledge of design patterns helps in such scenarios. Essentially, Design patterns describe a problem which occurs over and over again in an environment, and then describes the core of the solution to that problem, in such a way that one can use this solution a million times over, without ever doing it the same way twice

Classes of Design Patterns

Design patterns are generally classified into the one of the following three categories.

Creational Pattern, which help create the objects for the user, instead of having the user to instantiate the object.

Structural Pattern, which employ interfaces to achieve inheritance to enable objects to obtain new functionality.

Behavioral Pattern, which are concerned with communication between objects.

Builder Pattern

The intent of Builder pattern is to separate the construction of a complex object from its representation so that the same construction process can create different representations. According to GOF [1], the builder pattern can be applied when
1. The algorithm for creating a complex object should be independent of the parts that make up the object and how they're assembled.
2. The construction process must allow different representations for the object that's constructed.

Let us consider an example for builder pattern. Consider a word processing software that should have the ability to convert Microsoft word's DOC to many text formats. The reader might convert *.DOC documents into plain ASCII text or into a PDF. 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 DOCReader class with a TextConverter object that converts DOC to another textual representation. As the DOCReader parses the DOC document, it uses the TextConverter to perform the conversion. Whenever the DOCReader recognizes an DOC 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 PlainTextConverter ignores requests to convert anything except plain text. A LaTeXConverter, on the other hand, will implement operations for all requests in order to produce a LaTeX representation that captures all the stylistic information in 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 DOC document. Converter class designed as discussed above basically defines the builder design pattern.