An introduction to design patterns Based on material

An introduction to design patterns Based on material produced by John Vlissides and Douglas C. Schmidt 1

Background • object-oriented design is hard • good OO designers rely on lots of experience • OO systems contain recurring structures that exhibit – abstraction, modularity, elegance, and flexibility – balancing between various design trade-offs – valuable design knowledge • most general reuse is design reuse – matching problems to design experiences Problem: capturing, communicating, and applying this knowledge 2

A design pattern 1. Name - plus possible aliases 2. Problem - including context and forces 3. Solution - structure, dependencies & interactions 4. Consequences - plus alternative implementation strategies and trade-offs 3

A design pattern (cont. ) • a micro-architecture – class/object interactions as a unit – improve flexibility and restructuring – distill and generalize oo design experience • language- and implementation-independent – described by simple UML diagrams – aid to novices and experts alike • common vocabulary – enhance understanding, documentation, and team communication 4

Example: The Observer design pattern • known uses: Smalltalk Model-View-Controller (MVC), GUI component listeners in Java 5

Example: Observer (cont. ) • define an one-to-many dependency between objects so that when one object changes, all dependents are notified and updated – decoupling of subjects and observers – different observers offer different views of subject – can define and add any number of observers Structure 6

Principles of design patterns • patterns give recurring solutions to (nontrivial) problems; solutions that have been tried over and approved by experts – design patterns are not invented but found (in existing systems) • often provide a level of indirection that keeps classes from having to know about each other’s internals – give ways to make some structures or behavior modifiable or replaceable – usually, by objectifying some aspect of the system • generally, help you write more reusable programs 7

Principles of design patterns (cont. ) Different kinds of practices and reusable designs: (1) idioms - techniques for expressing low-level, mostly language-dependent ideas – e. g. , ref counts in C++, inner classes in Java (2) design patterns - medium-scale, mostly languageindependent abstractions – use oo mechanisms, described by UML diagrams (3) software frameworks - consist of source code with variant parts, into which the user can plug-in specific code to provide the required structure and behavior – GUI libraries, data structure libraries 8

The Composite design pattern • treat multiple individual objects and recursivelycomposed objects (trees) uniformly – provides extensibility: new components work wherever old ones do • known uses: file directories, abstract syntax trees (AST), Java GUI component-container Structure other versions have been presented 9

The Strategy design pattern • encapsulate a family of algorithms, and make them interchangeable – can change algorithms dynamically (at run time) – in C++, static strategy selection can be done via templates and type parameters • known uses: ordering relation for data structures, GUI component layout managers Structure 10

The Iterator design pattern • access elements of a container without exposing its representation – multiple traversal algorithms over a container – container classes and traversal algorithms can vary independently • known uses: C++ STL, Java Iterators; originally: Clu Structure 11

Other design patterns • the Template Method makes part(s) of an algorithm changeable: the skeleton of an algorithm defers some steps to subclasses • the Singleton ensures a class only has one instance, and provides a global point of access to it (i. e. , manages global objects) • the Bridge pattern separates interface and implementation hierarchies, and allows them vary independently (e. g. , Java GUI peer components) • the Abstract Factory provides an interface for creating families of related or dependent objects without specifying their concrete classes – uses Factory Methods or Prototypes to create the actual instances; the factory object is often a Singleton 12

Design space for Go. F patterns scope: domain over which a pattern applies purpose: reflects what a pattern does 13

Drawbacks/limitations of design patterns • a pattern is an idea of solution: may require tedious and error-prone human effort to implement as code – but may provide the basis for automation • cannot apply them blindly – must consider what design aspects are variable – a pattern may leave important details unresolved – added indirection increases complexity and cost • don't label everything a design pattern – state a specific but general problem and benefits – must demonstrate wide applicability (at least three examples - from code other than your own) – pattern design even harder than OO design 14