Design Patterns

1
Design Patterns

• Based on Gamma, Helm, Johnson, Vlissides Design
  Patterns
• Viviane Jonckers

2
Patterns and Frameworks

• A class is a mechanisms for encapsulation, it
  embodies a certain service providing the data and
  behavior that is useful in the context of some
  application. A single class is rarely the
  complete solution to some real problem
• There is a growing body of research in describing
  the manner in which collections of classes work
  together in the solution of problems. Application
  frameworks and design patterns are two ideas that
  became popular in this context

3
Application Frameworks

• An application framework is a set of classes that
  cooperate closely with each other and together
  embody a reusable design for a general category
  of problems
• Although one might abstract and discuss the
  design elements that lie behind the framework,
  the framework itself is a set of specific classes
  that are typically implemented only on a specific
  platform or limited set of platforms
• The framework dictates the overall structure and
  behavior of the application. It describes how
  responsibilities are partitioned between various
  components and how these components interact

4
A Framework as an Upside-down Library

• In a traditional application the
  application-specific code defines the overall
  flow of execution through the program
  occasionally invoking library-supplied code
• A framework reverts this relation the flow of
  control is dictated by the framework and the
  creator of a new application merely changes some
  of the methods invoked by the framework
• Inheritance is often used as powerful mechanism
  for achieving this. Alternatively
  application-specific components that obey a
  specified interface are plugged in

5
Application Framework Example (1)

• GUI application frameworks simplify the creation
  of graphical user interfaces for software systems
• A GUI application framework implements the
  behavior expected from a graphical user interface
  (hold windows, buttons, menu's, textfields, etc.
  - move and resize windows - handle mouse events
  on buttons and menus- ...)
• A new application is build by specifying and
  arranging the necessary elements (buttons,
  menu's, textfields, etc. ) and by redefining
  certain methods (responses to the mouse and key
  events - )

6
Application Framework Example (2)

• Simulation frameworks simplify the creation of
  simulation style applications
• A simulation framework provides a general-purpose
  class for managing the types of objects in the
  simulation
• The heart of a simulation framework is a
  procedure that cycles through the list of objects
  introduced in the simulation asking each to
  update itself
• The framework knows nothing about the particular
  application it is going to be used for billiard
  balls, fish in a tank, rabbits and wolves in an
  ecological game, etc.

7
Design Patterns

• Design patterns are an attempt to collect and
  catalog the smallest recurring architectures in
  object oriented software systems. A design
  patterns typically captures the solution to a
  problem that has been observed in many different
  systems
• Design patterns are more abstract than a
  framework. Frameworks are partial implementations
  of (sub)systems, design patterns have no
  immediate implementation at all
• Design patterns are smaller architectural
  elements than frameworks, most applications (and
  frameworks) will use several patterns
• Design patterns are architectural level
  counterparts of programming idioms

8
Design Patterns in Smalltalk MVC

• Model/View/Control is a triad of classes used to
  build interactive user interfaces in Smalltalk-80
• Model the application object
• View a screen presentation of an application
  object
• Controller defines the way the system reacts to
  user input
• 3 well known design patterns appear
• Observer MVC decouples views and models by
  establishing a subscribe/notify protocol between
  them
• Composite MVC supports nested views
• Strategy MVC encapsulates the response mechanism
  to user input in a controller object and allows
  to associate a controller with a view

9
MVC example 1
10
MVC example 2
11
MVC relations and interactions
Object references in MVC
Communication in MVC
12
The Elements of a Design Pattern

• A pattern name
• The problem that the pattern solves
• Including conditions for the pattern to be
  applicable
• The solution to the problem brought by the
  pattern
• The elements (classes-objects) involved, their
  roles, responsibilities, relationships and
  collaborations
• Not a particular concrete design or
  implementation
• The consequences of applying the pattern
• Time and space trade off
• Language and implementation issues
• Effects on flexibility, extensibility,
  portability

13
The Observer Pattern The Problem
Assume a one to many relationship between
objects, when one changes the dependents must be
updated
- different types of GUI elements depicting the
same application data - different windows
showing different views on the same application
model
Subject
Observers
Also known as Dependants, Publish-Subscribe
14
The Observer Pattern Participants

• Subject knows its observers, provides an
  interface for attaching (subscribe) and detaching
  (unsubscribe) observers and provides a notify
  method that calls update on all its observers
• Observer provides an update interface
• ConcreteSubject maintains a state relevant for
  the application at hand, provides methods for
  getting and setting that state, calls notify when
  its state is changed
• ConcreteObserver maintains a reference to a
  concrete subject, stores a state that is kept
  consistent with the subject's state and
  implements the observer's update interface

15
(No Transcript)
16
The Observer Pattern Collaboration

• ConcreteSubject notifies its Observers whenever a
  change occurs that could make its observers'
  state inconsistent
• After being informed of a change in the
  ConcreteSubject, a ConcreteObserver may query the
  Subject for information concerning its state and
  then reconcile its own state with that of the
  Subject
• The change in the ConcreteSubject can be
  initiated by one of the Observers or by some
  other application object

17
(No Transcript)
18
The Observer Pattern Consequences

• Abstract and minimal coupling between Subject
  and Observer the subject does not know the
  concrete class of any observer, concrete subject
  and concrete observer classes can be reused
  independently, subject and observer can even
  belong to different abstraction layers in the
  system
• Support for broadcast communication the
  notification a subject sends does not need to
  specify a receiver, it will broadcast to all
  interested (subscribed) parties
• - Unexpected updates observers dont have
  knowledge about each others presence, a small
  operation might cause a cascade of spurious
  updates

19
The Observer Pattern Implementation (1)

• Mapping subjects to their observer the Subject
  keeps explicit references to the Observers it
  should notify or some associative lookup (e.g. a
  hash table) is installed memory/time trade off
  must be made
• Observing more than one Subject can make sense
  in some situations the update interface must be
  extended to keep track of the Subject that is
  sending the update allowing the Observer to know
  which Subject to examine
• Who triggers the updates (i.e. who calls
  notify)
• have all state changing operations on Subject
  call notify after the subjects state is changed
  consecutive operations cause several consecutive
  updates which may not be necessary and is
  inefficient
• make clients responsible for calling notify at
  the right time clients get the added
  responsibility to call notify which makes errors
  likely

20
The Observer Pattern Implementation (2)

• Dangling references to deleted Subjects deleting
  a Subject should not produce dangling references
  in its Observers simply deleting the Observers
  is often not the best idea (they can be
  referenced by others or they can be observing
  another Subject) when deleting a Subject the
  Observers should be notified so that they can
  reset their Subject reference
• Make sure that Subject is self consistent before
  calling notify Observers query the subject's
  state to do their update this rule is easy to
  violate unintentionally when Subject subclass
  operations call inherited operations
• Specifying modification of interest explicitly
  update efficiency can be improved when the
  observers register for specific events of
  interest only

21
The Observer Pattern Implementation (3)

• Avoiding observer-specific update protocols, the
  pull and the push model
• In the push model the Subject sends its Observers
  detailed information on what is changed the
  Subject class makes assumptions about the
  Observers needs
• In the pull model the Subject sends nothing but
  the most minimal notification and the Observers
  ask for details explicitly emphasizes the
  Subjects ignorance of its Observers can be
  inefficient because Observers must assess what is
  changed without help
• Encapsulate complex update semantics install an
  explicit change manager that manages the
  Subject-Observer relationships and defines a
  particular update strategy

22
(No Transcript)
23
Sorts of Design Patterns
Creational Patterns are concerned with the
process of object creation

Behavioural Patterns are concerned with
algorithms and the assignment of
responsi- bilities between objects
Structural Patterns are concerned with how
classes and objects are composed to form larger
structures
Class Patterns deal with static relationships
between classes and subclasses
Object Patterns deal with object relationships
which can be changed at run time
scope
24
Creational Design Patterns

• Abstracts the instantiation process
• Encapsulates knowledge about which concrete
  classes to use
• Hides how the instances of these classes are
  created and put together
• Gives a lot of flexibility in what gets created,
  who creates it, how it gets created, and when it
  it gets created
• A class creational pattern uses inheritance to
  vary the class that is instantiated
• An object creational pattern delegates
  instantiation to another object

25
Structural Design Patterns

• Structural design patterns are concerned with how
  classes and objects are composed to form larger
  structures
• A class structural pattern uses inheritance to
  compose interfaces or implementation
  compositions are fixed at design time
• An object structural pattern describes ways to
  compose objects to realise new functionality the
  added flexibility of object composition comes
  from the ability to change the composition at
  run-time

26
Behavioral Design Patterns

• Behavioral design patterns are concerned with
  algorithms and the assignment of responsibilities
  between objects
• Behavioral class patterns use inheritance to
  distribute behavior between classes
• Behavioral object patterns use object composition
  rather than inheritance some describe how a
  group of peer objects cooperate to perform a
  tasks no single object can carry out by itself
  others are concerned with encapsulating behavior
  in an object and delegating request to it

27
Overview

• Behavioral Patterns
• Chain of Respons.
• Command
• Interpreter
• Iterator
• Mediator
• Memento
• Observer
• State
• Strategy
• Template Method
• Visitor

• Structural Patterns
• Composite
• Façade
• Proxy
• Flyweight
• Adapter
• Bridge
• Decorator

• Creational Patterns
• Singleton
• Abstract factory
• Factory Method
• Prototype
• Builder

28
Lexi WYSIWYG document editor

• Document is mix of text and graphics in variety
  of formatting styles
• Document in middle area
• Pull-down menu's and scroll bars
• Icons for navigating the document

29
Design problems (1)

• Document structure - the choice of an internal
  representation for the document has impact on
  other aspects of Lexi's design because editing,
  displaying, textual analysis, etc. requires to
  traverse the representation
• Formatting - how does Lexi arrange text and
  graphics in lines and columns, how to manage
  different formatting policies, how do these
  policies interact with the document's internal
  representation
• Embellishing the user interface - Lexi's
  interface includes scroll bars, borders, menu's,
  etc. that are likely to change as the user
  interface evolves, it is important to be able to
  add and remove embellishments without changing
  the rest of the application

30
Design problems (2)

• Supporting multiple look-and-feel standards -
  Lexi should adapt easily to different look and
  feel standards such as Motif and PM
• Supporting multiple window systems - different
  look-and-feel standards are implemented on
  different window systems, Lexi needs to be as
  independent of the window system as possible
• User operations - users control Lexi through
  various user interface elements (buttons, menu's,
  etc.), the functionality behind these interface
  elements is scattered, but Lexi must support undo
• Spelling checking and hyphenation - Lexi supports
  analytical operations such as spelling checks and
  hyphenation, how to minimize the changes
  necessary to accommodate a new analytical
  technique

31
Document Structure

• The internal representation should support
• Maintaining the document's physical structure,
  I.e. the arrangement of text and graphics into
  lines, columns, tables etc.
• Generating and presenting the document visually
• Mapping positions on the display to elements of
  the internal representation
• Additional constraints are
• Treat text and graphic uniformly
• Treat simple and complex (composed) element
  uniformly
• Allow extra features for some elements (ex.
  hyphenate text elements while it makes no sense
  to hyphenate a picture)

32
Recursive composition
33
Document Structure as a Composite pattern
34
Formatting

• The internal representation can capture a
  document's structure but it does not tell how to
  arrive at it
• Formatting means breaking collections of glyphs
  into lines, lines into columns, columns into
  pages, etc.
• Formatting algorithms are complex, it is
  important to keep them well contained and
  independent of the document structure
• Many formatting algorithms exist (trade off
  time/quality)
• Goal it must be easy to replace the formatting
  algorithms used (at compile time or even at run
  time)

35
Formatting (composition) with the Strategy
Pattern
36
Object structure reflecting compositor-directed
line breaking
37
Embellishing the User Interface

• Two examples
• Add a border around the text editing area to
  demarcate the page of text
• Add scroll bars to allow users to view different
  parts of a page
• Goal
• Make it possible to add en remove embellishments
  without changing other classes

38
Embellished glyphs through the Decorator pattern

• Transparent Enclosure
• Single-component composition
• Compatible interfaces, clients do not know
  whether they they deal with the component or with
  its enclosure
• The enclosure augments the component behavior by
  doing extra's before or after delegating an
  operation

MonoGlyphDraw _componentDraw
BorderDraw MonoGlyphDraw
Drawborder
39
Embellished object structure
40
Supporting multiple look-and-feel standards

• Portability across hardware and software
  platforms is a wanted feature for many
  applications
• Platforms often come with a specific
  look-and-feel standard (how the applications
  appear and react through widgets such as buttons,
  menus and scrollbars)
• Application that runs on more than one platform
  must conform to the user interface style guide on
  each platform
• Goal make Lexi conform to multiple existing
  look-and-feel standard and to make it easy to add
  support for new standards that arise

41
GUIFactory class hierarchy of Lexi as used in the
Abstract Factory pattern
42
Abstract product classes and concrete subclasses
of Lexi as used in the Abstract Factory pattern
43
Supporting multiple window systems

• The windowing environment in which an
  application runs is another portability issue (it
  is the windowing system that creates the illusion
  of multiple overlapping windows on a bitmapped
  screen - it manages screen space and routes input
  to them from keyboard and mouse)
• Several important windowing systems exist
  (Macintosh, Windows, X) with largely incompatible
  programming interfaces
• Goal make Lexi portable over multiple windowing
  environments
• Applying the Abstract Factory pattern again is
  not really an option because we want to reuse the
  existing windowing system implementations and not
  build our own full windowing system

44
An abstract window class for Lexi and its
subclasses targeted at the application programmer
45
Relate Windows and Window Implementations through
the Bridge pattern
46
User operations

• Lexi's functionality comes in two kinds
• Directly through the document's WYSIWYG
  representation enter and delete text, move the
  insertion point, select text by pointing and
  clicking, etc.
• Indirectly through menus, buttons and keyboard
  commands create, open, save, close a document,
  cut, copy and paste a selection, change font or
  style, etc.
• Goals
• Support one operation through multiple command
  types
• Avoid dependencies between user interface and
  application classes
• Support undo end redo of some (but not all)
  operations

47
Command class and subclasses
48
Relate menu items and commands
49
Unexecute and the command history
50
Spelling checking and hyphenation

• Goals
• Support multiple algorithms
• Make it easy to add new analysis algorithms
• Two pieces to the solution
• Accessing the information to be analysed that is
  scattered over the glyphs -gt the Iterator pattern
  encapsulates access and traversal
• Do the analysis -gt the Visitor pattern
  encapsulated the analysis algorithm

51
Iterator class and subclasses
52
Traversal versus Traversal Actions