Browser Advisory: The HTML version of this textbook requires a browser that supports the display of MathML. A good choice as of April 2022 is a recent version of Firefox from Mozilla.

Chapter Introduction

TODO: This set of slides is not fully compatible with the chapter as of 16 April 2022.

Approach

• Observe that we solve a new problem by applying a solution that worked on similar problem in past

• Document problem and solution pair to enable reuse

Concept of Design Pattern

• Arose originally in field of (building) architecture in 1970’s — Christopher Alexander

• Imported into software architecture and design in late 1980’s and 1990’s

Pattern

• Describes particular recurring design problem that arises in specific design contexts

• Presents well-proven generic scheme for solution

  • specified by describing constituent components, their responsibilities and relationships, and ways they collaborate

Characteristics of Patterns (1)

• Describe solutions to recurring problems that arise in specific design situations

• Distilled from practical experience, not invented

• Describe group of components (classes or objects), how components interact, responsibilities of each

  • Higher level abstractions than classes or objects

• Provide vocabulary for communication among designers

  • Choice of name for pattern very important

Characteristics of Patterns (2)

• Help document architectural vision of a design

  • If vision clearly understood, then less likely violated when system modified

• Provide conceptual skeleton for solution, encourage construction of software with well-defined properties

• Are building blocks for construction of complex designs

• Help designers manage complexity of software

Description of Pattern

Buschmann et. al. [1] approach. Others differ in structure but have same purpose.

1. Context

2. Problem

3. Solution

Description of Pattern: Context

• Describes situation in which design problem arises

Description of Pattern: Problem

• Describes problem that arises repeatedly in Context

• Describes set of forces — aspects that must be considered when attempting solution

  • requirements solution must satisfy (e.g., efficiency)

  • constraints that must be considered (e.g., use of specific algorithm or protocol)

  • desirable properties of solution (e.g., easy to modify)

• Must balance complementary and contradictory forces to achieve good solution

Description of Pattern: Solution

• Describes proven solution to Problem

• Specifies configuration of elements to balance forces

  • Describes static structure of configuration, identifying components and connectors (relationships among components)

  • Describes dynamic runtime behavior of configuration, identifying control structure of components and connectors

Categories of Patterns

1. Architectural patterns

2. Design patterns

3. Idioms

Architectural Pattern

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

• High-level abstraction

• Fundamental design decision in development of system

• Independent of implementation language

Architectural Pattern Examples

From Buschmann et al. [1] unless otherwise noted

• Pipes and Filters (or Pipeline)
• Layered Systems
• Blackboard (or Repository)
• Model-View-Controller
• Data Abstraction [3,4]
• Communicating Sequential Processes [3,4]
• Implicit Invocation [3,4]

Design Pattern

“A design pattern provides a scheme for refining the subsystems 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” [1]

• Mid-level abstraction

• Affects the structure of a subsystem

• Independent of implementation language (but might not be independent of paradigm)

Design Pattern Examples (1)

Names from Gamma et al. [2] unless otherwise noted

• Creational patterns
  • Abstract Factory
  • Builder
  • Factory Method
  • Prototype
  • Singleton

Design Pattern Examples (2)

Names from Gamma et al. [2] unless otherwise noted

• Structural patterns
  • Adapter
  • Bridge
  • Composite
  • Decorator
  • Facade
  • Flyweight
  • Proxy

Design Pattern Examples (3)

Names from Gamma et al. [2] unless otherwise noted

• Behavioral patterns
  • Chain of Responsibility
  • Command
  • Interpreter (also architectural [3])
  • Iterator
  • Mediator
  • Memento
  • Null Object [5]
  • Observer
  • State
  • Strategy
  • Template Method
  • Visitor

Idiom

“An idiom is a low-level pattern specific to a programming language. An idiom describes how to implement particular aspects of components or the relationships between them using the features of the given language” [1]

• Low-level abstraction

• Examples:

  • Language-specific iterator defined to implement interface Iterator in Java
  • Counted Pointer (Reference Counting) for storage management of shared objects in C+

Acknowledgementa

These slides are based partially on my notes titled “Introduction to Patterns”. The original version of these slides (in Powerpoint) was supported by a grant from the Acxiom Corporation titled “The Acxiom Laboratory for Software Architecture and Component Engineering (ALSACE)” in 2004. The research team consisted of Dr. Conrad Cunningham, PhD students Yi Liu and Pallavi Tadepalli, and MS students Mingxian Fu and Hui Xiong.

References