Design patterns

A design pattern provides a scheme for refining the subsystems or components of a software system, or the relation ships between them. It describes a commonly-recurring structure of communicating components that solves a general design problem within a particular context.

Framework
A framework is a partially complete software (sub-) system that is intended to be instantiated. It defines the architecture for a family of (sub-) systems and provides the basic building blocks to create them. It also defines the places where adaptations for specific functionality should be made.

Patterns vs “Design”
=>Patterns are design
* But: patterns transcend the “identify classes and associations” approach to design
* Instead: learn to recognize patterns in the problem space and translate to the solution
=>Patterns can capture OO design principles within a specific domain
=>Patterns provide structure to “design”

Patterns vs Frameworks
=>Patterns are lower-level than frameworks
=>Frameworks typically employ many patterns:
* Factory
* Strategy
* Composite
* Observer
=>Done well, patterns are the “plumbing” of a framework

Patterns vs Architecture
=>Design Patterns (GoF) represent a lower level of system structure than “architecture” (cf: seven levels of A)
=>Patterns can be applied to architecture:
* Mowbray and Malveau
* Buschmann et al
* Schmidt et al
=>Architectural patterns tend to be focussed on middleware. They are good at capturing:
* Concurrency
* Distribution
* Synchronization