CSC/ECE 517 Fall 2009/wiki2 12 Schemes for Pattern Classification

Overview

Design patterns in software engineering is a time-tested reusable solution to recurring problems in software design. The origin of design patterns can be owed to the work of civil engineer Christopher Alexander, who documented his resolution to design issues in constructing buildings and towns[1]. About a decade and a half ago, software professional began to incorporate Alexanders ideas into guides for novice developer. From then on design patterns became increasingly popular.

Schemes for Pattern Classification

Gang of Four's Classification

Design Patterns gained popularity with the book Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides published in 1995. In their work they used 2 criteria to categorize 23 design pattern[2].

• What does the pattern do?
  • Structural - These patterns deal with the composition of classes and their object.
  • Creational - These patterns deal with object creation.
  • Behavioral - These patterns deal with the interaction between classes and object and how they delegate responsibility.

• What is the scope of the pattern?
  • Class - The patterns deal with the relationships between classes and their subclasses. These are more static and fixed at compile time.
  • Object - These patterns deal with object relationship. They are more dynamic and can vary at runtime.

Example of Design Patterns that fall into each Category

Purpose
Scope	Creational	Structural	Behavioral
Class	Factory Method	Adapter (class)	Interpreter
			Template Method
Object	Abstract Factory	Adapter (object)	Command
	Prototype	Composite	Mediator
	Builder	Bridge	Iterator
	Singleton	Decorator	Memento
		Facade	Observer
		Flyweight	State
		Proxy	Strategy
			Visitor
			Chain Of Responsibility

Zimmer's Classification

Zimmer[3] classifies the relationships between the Gang of Four design patterns. Focusing on the problem and solution of each relationship, they can be classified as :

• X uses Y in its solution.
  • The Interpreter design pattern uses the Composite design patter.
  • The Prototype design pattern uses the Singleton design pattern.
• Variant of X uses Y in its solution.
  • Some variant of the Bridge design pattern may uses the Adapter design pattern.
• X is similar to Y.
  • The Mediator design pattern is similar to the Facade design pattern.

Using these relationships Zimmer placed design pattern in 3 layers.

Layer	Design Pattern
Basic design patterns and techniques.	Singleton, Template Method, Mediator, Facade, Memento, Iterator, Flyweight.
Design patterns for typical software problems.	Abstract Factory, Builder, Strategy, Observer, Bridge, Adapter, Prototype, Factory Method, State, Command, Visitor, Composite, Decorator, Chain Of Responsibility, Proxy
Design patterns specific to an application domain.	Interpreter

Tichy's Classification

Walter Tichy classified several design patterns based on the kind of problems they solved. He grouped the problems into the following high-level categories[6]:

• Decoupling: dividing a software system into in-dependent parts in such a way that the parts can be built, changed, replaced, and reused independently. Decoupling patterns can be further classified into:
  • Modules(Encapsulation/Information Hiding): The purpose of this design pattern is to hide data structure and operations that are most likely to change, thus protecting other parts of the system from the effects of those changes. Examples for support of modules are
    • Modula's modules.
    • C's header files.
    • Ada's packages.
  • Abstract Data Type[ADT]: Some examples of ADT

• Variant Management: treating different objects uniformly by factoring out their commonality.
• State Handling: generic manipulation of object state.
• Control: control of execution and method selec-tion.
• Virtual Machines: simulated processors.
• Convenience Patterns: simplified coding.
• Compound Patterns: patterns composed from others, with the original patterns visible.
• Concurrency: controlling parallel and concurrent execution.
• Distribution: problems germane to distributed systems.

References

[1] http://www.developer.com/design/article.php/1474561/What-Are-Design-Patterns-and-Do-I-Need-Them.htm
[2] http://www.cs.umu.se/~jubo/ExJobbs/MK/patterns.htm
[3] Relationships between Design Patterns, by Walter Zimmer, Forschungszentrum Informatik, Bereich Programmstrukturen, 1995
[4] Peter Coad, with David North, and Mark Mayfield. Object Models: Strategies, Patterns, and Applications. Englewood Cliffs, NJ: Prentice Hall, 1995.
[5] Wolfgang Pree. Design Patterns for Object-Oriented Software Development. Addison-Wesley, 1995.
[6] Tichy, Walter F (1998), A Catalogue of General-Purpose Software Design Patterns. University of Karlsruhe, Karlsruhe, Germany.
[7] Some Patterns for Software Architectures, Mary Shaw, Carnegie Mellon University