By By Paul E. Sevinç, Switzerland
Reuse is a key objective of software engineering. A well-known form of reuse is code (i.e., implementation) reuse, as promoted by a procedure library for instance. A domain-specific framework also promotes implementation reuse, and in addition the reuse of analysis (namely of the domain) and design (that led to the architecture of the framework). Capturing and passing on analysis and design experience without the need for code can be achieved by the use of patterns.
In this article, we give definitions of pattern, analysis pattern, design pattern, and architectural pattern. (In a future article on frameworks, we will also discuss the relationship between patterns and frameworks.) We do not, however, recap the history of patterns (see, for instance, Appleton [3]). Nevertheless, note that software-development patterns were inspired by Christopher Alexander who, in the 1970s, developed a pattern language for architecture [2]-the "house-building" discipline, that is, not software or computer architecture!
Patterns are schematic, proven solutions to recurring problems. Basically, patterns are characterized by at least a name, a problem description, and a problem solution [15]. A well-known name allows us to concisely refer to a specific pattern. It is certainly easier to refer to "the Adapter pattern" (see the example below) than "the pattern that consists of entities which...". The problem description tells us in what situations the respective pattern is applicable. It includes conditions that must be met before applying the pattern. The problem solution explains how we can solve the problem. It typically does so as abstractly as makes sense for the particular kind of pattern.
"Schematic" refers to the fact that, especially in patterns books, patterns are usually discussed according to some template. (For the sake of brevity, we will not do that in this article.) Different authors use different templates [e.g., 6, 11]. "Recurring" refers to the fact that a problem/solution pair must be observed at least three times to be accepted as a pattern.
Let us look at a simple example, the Adapter pattern. Assume that, in a certain context, we defined the interface of encryption/decryption Java classes to be as shown in Listing 1.
Listing 1
public interface Cipher
{
void encrypt( int[] plainText, int[] cipherText );
void decrypt( int[] cipherText, int[] plainText );
}
Now we would like to have a Cipher instance that performs IDEA-encryption and -decryption [14]. For that, we need a concrete class that implements the Cipher interface. We could, of course, develop such a class from scratch. However, a good soul already did most of the hard work by developing a class that realizes IDEA and even made its source code freely available (see Listing 2). We are going to reuse this class.
Listing 2
public class IDEA
{
// fields
...
public IDEA( int[] secretKey )
{
...
}
public void cipher( boolean flag, int[] source, int[] drain )
{
...
}
// private methods
...
}
One problem remains, though: the type IDEA is not a subtype of Cipher, but Java is strongly typed. And even if Java was not strongly typed, we would still have a problem since the interfaces did not match in the first place.-Enter the Adapter pattern. Instead of forgetting about the IDEA class altogether or of copying and modifying its source code (a highly error-prone approach), the Adapter pattern suggests to develop a class, a subtype of Cipher, that simply forwards requests to IDEA (see Listing 3).
Listing 3
public final class IDEACipher implements Cipher
{
private final static int keyLength = 16;
private final IDEA adaptee;
public IDEACipher( int[] key ) throws InvalidKeyException
{
if ( key.length != keyLength ) {
throw new InvalidKeyException( "..." );
}
for ( int i = 0; i < keyLength; ++i ) {
if ( key[ i ] < 0 || key[ i ] > 255 ) {
throw new InvalidKeyException( "..." );
}
}
adaptee = new IDEA( key );
}
public void encrypt( int[] plainText, int[] cipherText )
{
adaptee.cipher( true, plainText, cipherText );
}
public void decrypt( int[] cipherText, int[] plainText )
{
adaptee.cipher( false, cipherText, plainText );
}
}
Note that, since IDEA was developed first, we could also have defined IDEACipher as shown in Listing 4.
Listing 4
public final class IDEACipher extends IDEA implements Cipher
{
// see Listing 3
...
public void encrypt( int[] plainText, int[] cipherText )
{
super.cipher( true, plainText, cipherText );
}
public void decrypt( int[] cipherText, int[] plainText )
{
super.cipher( false, cipherText, plainText );
}
}
Figure 1. Object Adapter (adapted from [11])
The Adapter variant of Listing 3 is called the Object Adapter (it connects objects at run time through a reference, see Figure 1). The Adapter variant of Listing 4 is called the Class Adapter (it connects classes at compile time through inheritance, see Figure 2). In Java, we clearly prefer the Object Adapter over the Class Adapter. But in C++, where IDEACipher could have inherited privately from IDEA (and thus not be of type IDEA), the Class Adapter is a viable alternative.
Figure 2. Class Adapter (adapted from [11])
In short: Name: Adapter (also know as Wrapper)
Problem Description: Class (Adaptee) whose implementation cannot be reused (by Client) because its type or at least its interface does not meet certain requirements.
Problem Solution: Develop a class (Adapter) whose type or interface does meet above-mentioned requirements and whose implementation mainly consists of forwarding requests to (and returning replies from) Adaptee in a suitable form.
According to Stroustrup [23], software development is an iterative and incremental process basically consisting of analysis, design, and implementation, where the software design steps result in the software architecture. This view of architecture being the result of design is not uncommon. And we adopted it in the first paragraph of the introduction, when we said that framework design leads to the framework architecture.
However, the software-engineering community in general and the patterns community in particular denote by architecture another software-development step (analysis, architecture, design, implementation). We adopted the latter view in the last paragraph of the introduction, when we considered architecture to be a discipline, and for the remainder of this article.
So what is architecture? Just as is the case for components [22, CS99], the software-engineering community is struggling with a definition for architecture [4, 7]. Very, very loosely speaking, architecture is coarse-grained design (higher level), and design is fine-grained architecture (lower level).
Many kinds of patterns exist. And more often than not, there are different definitions for the "same" kind of pattern. A prime example is the term "design pattern" which sometimes denotes patterns in general and sometimes a particular class of patterns (as it does in this article).
As a basis for further discussion, we quote five definitions from the literature:
Analysis Pattern
Richter [16, p. 344]:
"An analysis pattern is a way of solving a problem in a particular problem domain."
Architectural Pattern
Richter [16, p. 345]:
"An architectural pattern is a problem-independent way of organizing a system or subsystem. It describes a structure by which the different parts of a system are organized or interact."
Buschmann et al. [6, p. 12]:
"An architectural pattern expresses a fundamental structural organization schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them."
Design Pattern
Richter [16, p. 345]:
"A design pattern is a solution to a small problem that is independent of any problem domain. It represents an attractive solution to a design problem that could occur in any kind of application. The same design pattern can be applied in areas as diverse as order processing, factory control, and meeting room scheduling."
Buschmann et al. [6, p. 13]:
"A design pattern provides a scheme for refining the subsystem or components of a software system, or the relationships between them. It describes a commonly-recurring structure of communicating components that solves a general design problem within a particular context [11]." (Note: here, "component" means software entities in general, not components in the more narrow sense of component-oriented programming [22, CS99].)
Examples
Example analysis patterns can be found in Fowler's book [8] and on his homepage [9].
Probably one of the most successful architectural patterns is the Layers [6, p. 31]:
"The Layers architectural pattern helps to structure applications that can be decomposed into groups of subtasks in which each group of subtasks is at a particular level of abstraction."
Figure 3. Layers [6]
Well-known examples of the Layers pattern are the ISO Open System Interconnection (OSI) model (layers: application, presentation, session, transport, network, data link, and physical) or the Java platform (host operating system, Java run-time environment, Java application). Buschmann et al. [6] and Szyperski [24] discuss several variants of Layers.
We do not need to discuss this pattern any further as you are most certainly very familiar with this fundamental architecture. And even if you are not impressed by the Layers at all, it is an excellent example: Patterns are about sound solutions to realistic problems, not about the most elaborate solution to an exotic problem.
The Adapter pattern is one example of a design pattern. Another one is the Wrapper Facade [20]:
"The Wrapper Facade design pattern encapsulates the functions and data provided by existing non-object-oriented APIs within more concise, robust, portable, maintainable, and cohesive object-oriented class interfaces."
Figure 4. Wrapper Facade [20]
As shown in Figure 4, the intent of the Wrapper Facade is to keep an object-oriented application purely object-oriented even though it relies on a procedure-oriented library. Again, the pattern is about an easy-to-understand solution to an easy-to-understand problem.-Nevertheless, the study of patterns is worthwhile: quite a few patterns discuss not-so-obvious (albeit highly elegant) solutions to non-trivial problems.
Discussion
First, note how Richter emphasizes the domain-specific nature of analysis patterns and the domain-independent nature of architectural and design patterns. (Riehle and Züllighoven [18] make a similar distinction between conceptual patterns and design patterns.) Do not take these definitions too literally, though. As Fowler remarks [10], an analysis pattern from one domain can prove useful in a completely different domain. And sooner or later, you will stumble over deceptively contradictory patterns categories such as "security architectural patterns" or "GUI design patterns". This can either mean that a set of general-purpose patterns has been collected for a particular domain, or that a pattern is domain-specific (e.g., for GUIs) but still general enough to be applicable in different situations within that domain (e.g., for different widgets).
Next, both architectural patterns and design patterns are language independent. (Language dependent patterns are called idioms [6] or programming patterns [18], by the way.) And architectural patterns are also paradigm independent. The layers in Figure 3 could each consist of a set of procedures, or some could consist of classes and some of functions, etc. Design patterns on the other hand are typically object oriented. The Wrapper Facade is a border case.
Finally, rotate Figure 4 by 90 degrees and you will see-the Layers (layers: Application, WrapperFacade, Functions)! It should come to no surprise that design patterns refine architectural patterns. However, sometimes it is difficult to determine which design pattern to apply for the refinement. As we said in the introduction, patterns help capturing and passing on experience, but they do not make experience obsolete.
A good starting point for pattern-related information on the Web is the patterns home page of the Hillside group [12]. And many authors of the patterns community provide information on their personal home pages (e.g., Riehle [17] or Schmidt [19]).
A must-read is Gamma et al.'s Design Patterns [11]. The publication of this seminal book triggered the intensive search for patterns that continues unabated today. Code examples are given in C++ and Smalltalk, so you may want to take a look at Lalonde's article [13]. We hope that the authors will take the time to publish a second edition. This would allow them to modify the diagrams to be UML compliant and to extend the "Known Uses" sections with examples from the Java platform.
A should-read is Buschmann et al.'s Pattern-Oriented Software Architecture [6] which pioneered architectural patterns. In newer publications, this book is also referred to as POSA 1, because other books with the same main title have been published or are in preparation.
The patterns community has its own conference and publishes the proceedings in the Pattern Language of Program Design series [1].
One book you may want to take a look at as well is Brown et al.'s AntiPatterns [5], some sections of which are pretty good while others cannot keep up with the rest of the book. Whether antipatterns really are a concept of their own or just patterns whose template also includes a bad problem "solution" encountered in practice is debatable.
Alas, now that patterns entered the mainstream, a few books are on the market that only try to cash in on a buzzworld-enabled title.
This article is partly based on a chapter in my M.S. thesis [21] that was proof-read and commented on by Prof. Dr. Rachid Guerraoui, Dr. Jean-Philippe Martin-Flatin, Luc Girardin, and Dani Seelhofer.
I would like to thank Dr. Dirk Riehle for proof-reading and commenting on the current version.
Paul E. Sevinç currently works as a software engineer for Switzerland-based Teamup AG. From January 2001 on, he will work for Trilogy Software, Inc. in Austin (Texas) and Paris (France). You can reach him at paul.sevinc@ubilab.org.
