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.

Based on purpose design patterns are classified into three types

• Creational Patterns
  • Examples: Factory Method, Singleton
• Structural Patterns
  • Examples: Adapter, Facade
• Behavioral Patterns
  • Examples: Chain of Responsibility, Iterator

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.

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.