CSC/ECE 517 Fall 2009/wiki2 12 01

Problem Statement

Patterns are often classified into creational, structural, and behavioral categories. However, this leaves a large number of patterns in each group, with no easy way of remembering all of them. What classifications and strategies have been developed to help programmers remember patterns, so that they can apply them at opportune moments?

Design Patterns

A design pattern in software engineering can be described as a reusable solution template to a frequently occurring software design problem.

Desirable Properties of Pattern Classification Schemes

• The schemes ought to be simple and easy to learn and use
• The criteria should be few in number
• The main properties of the patterns should be represented
• The classification scheme should facilitate easy selection of patterns
• Using the classification scheme it should be easy to classify new patterns
• The classification scheme should also capture the relationships between different patterns

Classification of Design Patterns

Design patterns can be classified along the following schemes

• Purpose
• Scope
• Functionality
• Structural Principles
• Granularity
• Domain
• Paradigm
• Domain-Dependent
• Process
• Analysis
• Reengineering
• Performance
• Maintenance

Purpose

Design patterns can also be classified according to what they are intended to achieve. This is in fact one of the most useful schemes of classification since it meets all the desirability requirements mentioned earlier.

In the book Design Patterns: Elements of Reusable Object-Oriented Software written by Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides design patterns are classified into three types based on purpose.

• Creational Patterns
  • Examples: Factory Method, Singleton

• Structural Patterns
  • Examples: Adapter,Facade
• Behavioral Patterns
  • Examples: Chain of Responsibility,Iterator

Scope

Design patterns can also be classified based on the features implementing the patterns. In the book Design Patterns: Elements of Reusable Object-Oriented Software patterns are classified into the following two categories based on scope

• Class representation: Uses inheritance
  • Examples: Adapter
• Object representation: Uses composition
  • Examples: Singleton, Adapter

Functionality

Schmidt, Douglas C.; Michael Stal, Hans Rohnert, Frank Buschmann classify patterns based on the functionality they are intended to achieve. The following are the categories

• Creation
  • Example: Factory Method, Singleton
• Communication
  • Example: Blackboard
• Access
  • Example: Proxy
• Organizing the computation of complex tasks
  • Example: Command

Structural Principles

In the book "Pattern-Oriented Software Architecture, Volume 2: Patterns for Concurrent and Networked Objects" by Schmidt, Douglas C.; Michael Stal, Hans Rohnert, Frank Buschmann patterns are classified based on the architectural principles they rely on. The categories are

• Abstraction
• Encapsulation
• Separation of concerns
• Coupling and cohesion

Granularity

Patterns can also be classified based on the level of granularity at which they can be applied. However several patterns can be applied at different levels of granularity. Based on this patterns are classified into the following types

• Architectural patterns: These are applied to software systems at a very high level
• Design patterns: These are applied to components and subsystems
• Idioms: These are coding patterns applied at the lowest level

Domain Specific Pattern Classification

Most of the patterns in the software engineering are known, but not restricted to, solving architectural and design problems. Patterns have been identified and proposed to address domain specific problems. Patterns have been applied to domains like Real Time Software System, User Interface, Embedded System and Distributed System etc… It is naturally easier for a Software engineer or Designer to remember the pattern according to domain and apply it on the problem at hand. This also reduces the overhead to looking up patterns that are not remotely related to domain. Below are two of the patterns classified for Real-time Systems by B. P. Douglass

• Latch : Remember that a pre-conditional state has been achieved for later synchronization
• Polling : Periodically perform an action.

Paradigm based Classification

Although patterns were initially a hit in object oriented software development, but the notion of patterns can be applied to other paradigms of programming languages. This provides opportunity for the programmers to lookup the patterns available for the paradigm they are using and apply the appropriate pattern suiting the problem at hand.

Following are examples of patterns that have been classified by S. Antoy and M. Hanus for “Functional logic languages”

• Opaque Type : Ensure that values of a datatype are hidden.
• Locally Defined Global Identifier:Ensure that a local name is globally unique.
• Incremental Solution : Compute solutions in an incremental manner.
• Concurrent Distinct Choices : Ensure that a mapping from indexes to values is injective.
• Constrained Constructor : Prevent invoking a constructor that might create invalid data.

Domain Dependent

This classification is based on the patterns that can only be implemented in a particular domain. However not all of the patterns can be classified strictly into it, as the pattern represent solution to a generalized problem. It is worthwhile to notice that due to inherent reasons in a domain a solution can be generalized over a class of problems in a domain. The generalized solution that are domain specific bring forth the need to classify these patterns. This classification also assists the programmer, if he encounters a problem he can look up if there exists a design pattern available to solve it elegantly.

• The most widely known example for a domain dependent design pattern “Session-Façade” in J2EE

References

• [1] S. Antoy and M. Hanus. “Functional Logic Design Patterns”. In Proc. Of the 6thInternational Symposium on Functional and Logic Programming (FLOPS 2002), Aizu (Japan), Springer LNCS 2441, pp. 67-87, 2002.
• [2] B. P. Douglass. “Doing Hard Time: Developing Real-Time Systems with UML, Objects, Frameworks, and Patterns”, Addison-Wesley, 19.
• [3] [Gamma95] E. Gamma, R. Helm, R. Johnson and J. Vlissides. “Design Patterns – Elements of Reusable Object-Oriented Software”, Addison-Wesley 1995.
• [4]Schmidt, Douglas C.; Michael Stal, Hans Rohnert, Frank Buschmann (2000). Pattern-Oriented Software Architecture, Volume 2: Patterns for Concurrent and Networked Objects. John Wiley & Sons. ISBN 0-471-60695-2.