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. [8]

Desirable Properties of Pattern Classification Schemes

We now present the desirable qualities for classification schemes of design patterns [7]

• 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 [7]

• Purpose
• Scope
• Functionality
• Structural Principles
• Granularity
• Domain
• Paradigm
• Domain-Dependent
• Re-engineering
• 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.

Design patterns are classified into three types based on purpose.[3]

• 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.[3]

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

Functionality

Design patterns can be classified based on the functionality they are intended to achieve.[4]

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

Structural Principles

Design patterns can also be classified based on the architectural principles they rely on.[4]

• Abstraction
  • Example: Facade
• Encapsulation
  • Example:Mediator
• Separation of concerns
• Coupling and cohesion
  • Example: Bridge

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
  • Example: Blackboard System
• Design patterns: These are applied to components and subsystems
• Idioms: These are coding patterns applied at the lowest level
  • Example: Incrementing a Counter

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 look up 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”[1]

• Opaque Type : Ensure that values of a data type 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

Re-engineering Patterns

To add to the classes of pattern classification, Re-engineering Patterns can be thought of as a good candidate. These patterens facilitate the improvement in maintainability, performance and to accommodate further changes to legacy systems.[5]

• For example the ”Split Up God Class”pattern addresses the problem of application functionality being concentrated in only one class, which uses other classes as data structures.

• Suggested solution includes:
  • Incrementally moving some functionality of the god class to other classes.
  • Creation of new classes.
  • Finally the god class remains as a facade or can be removed.

Performance Patterns

This classification aims at identifying patterns that facilitate to improve performance and scalability of software.[6]

• Fast Path pattern
  • aims at improving the response time by reducing processing required to access main functionality.

Maintenance Patterns

Also known as Evolution Patterns, these patterns aim at describing typical changes during lifetime of a software system. The name given to these patterns might force reader to get confused with Re-engineering Patterns. However, maintenance patterns are different from Re-engineering patterns. While Re-engineering patterns aims at identifying patterns based on addressing problematic situations during system's evolution, Maintenance patterns aims at finding common general rules how the system evolves

• Maintenance Patterns also document system-specific problems and code points where the system may be maintained.

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.
• [5]S. Demeyer, S. Ducasse and O. Nierstrasz. “Object-oriented Reengineering Patterns”, Elsevier Science 2003.
• [6]C. U. Smith and L. G. Williams. “Performance Solutions –A Practical guide to Creating Responsive, Scalable Software”, Addison-Wesley 2001.
• [7] http://www.cs.tut.fi/~kk/webstuff/PatternClassificationKalvot.pdf
• [8] http://en.wikipedia.org/wiki/Design_patterns