Short History Of Design Patterns

Well before software engineers started using patterns, an architect named Christopher Alexander wrote two books that describe the use of patterns in building architecture and urban planning. The first book is titled A Pattern Language: Towns, Buildings, Construction [Alex77], published in 1977. The second one is titled The Timeless Way of Building [Alex79], published in 1979. These two books not only changed the way structures were built, but they had a significant impact in another not closely related field, the field of software engineering.

According to Alexander, a pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million of times over, without ever doing it the same way twice [Alex77]. Although Alexander refers to buildings and towns, his conclusion can be successfully applied in the process of object-oriented design. Very often programmers have to solve the same problem that occurs in different applications regardless of the problem domain. Saving data in a database, for example, requires the same logic regardless of the amount and the nature of the data used. In the case of object-oriented databases, in order to read an object from the database, the following operations need to be accomplished:

A database session needs to be created in order to access any data in the database.

• Within the session, a transaction should be opened

• Within the transaction, object is read from the database

• If the transaction fails, a rollback to initial values occurs

• If the transaction succeeds, a commit occurs

• Transaction is closed

• Session is closed

These operations are repeated again and again every time an object is read or stored in the database. Therefore, they can be considered as a pattern that can be used by any programmer that needs to communicate with a database. The above list of operations is tested and proved to be correct. A novice programmer does not have to reinvent everything by himself; he can apply the read pattern and obtain the right results.

The first work on design patterns was undertaken by Cunnigham and Beck [CK87]. They presented five patterns for user interface design. In mid 90s, a group of four software engineers [GHJ95] wrote the book titled Design Patterns that had a significant impact in the way software design was carried out. The book presents well-thought solutions for a large class of problems. The same way an architect uses prefabricated blocks for building complex constructions, a programmer will use patterns to develop complex software. The concept of design patterns allows novice programmers to use elegant solutions provided by experts. Using patterns makes the process of designing complex systems easier.

Design patterns are divided in three categories: Creational, structural and behavioral patterns [GHJ95]. Some other authors such as Grand [Gra98] have created an additional group referred to as fundamental patterns where they include patterns that are used by other patterns. This book follows Grand's classification and starts the presentation of design patterns with fundamental patterns.

Creational patterns deal with the process of creating objects. They describe optimal ways of creating new objects. Structural patterns describe how to compose classes or objects. Behavioral patterns describe how to distribute behavior among classes and how classes interact with each other.

2. FUNDAMENTAL DESIGN PATTERNS 2,1 The delegation pattern

The purpose of the delegation pattern is to extend and reuse the functionality of a class by writing an additional class with added functionality that uses instances of the first class to provide the original behavior [Gra98].

Often, the reuse of the behavior of a class is realized through the mechanism of inheritance; a subclass inherits from its superclass data and behavior. Inheritance allows classes to be defined based on existing ones. When a new class of objects is defined, only the properties that will differ from the properties of the existing class need to be defined. Other properties defined in the existing class will be included in the new class definition. Therefore, inheritance is considered a mechanism for incremental programming. Code can be reused simply by inheriting it. Inheritance is a static relationship. When a class subclasses another one, their relationship is static and does not change over time.

Inheritance should be used only in the cases when the created subclass is a kind of the superclass, meaning that the subclass and the superclass are conceptually the same. The subclass should not radically alter the behavior of the superclass.

In cases when the existing behavior of a class needs to be extended and the result class is not conceptually similar to the superclass, inheritance should not be used. Another form of reuse, referred to as delegation, is the appropriate way to extend the behavior of a class as shown in Figure 7-1.

0 0

Post a comment