ObjectOriented Design Patterns

1
Object-Oriented Design Patterns

• Hip or Hype?

2
Design Patterns Defined

• A design pattern solves an OO architecture design
  problem in a specific context
• Four components
• A short pattern name
• A problem and its context
• A solution template
• Consequences of applying the pattern

3
Brief History of Patterns

• Introduced by Christopher Alexander in the
  context of town and building architectures
• Each pattern describes a problem which occurs
  over and over again in our environment, and then
  describes the core of the solution to that
  problem, in such a way that you can use this
  solution a million times over, without ever doing
  it the same way twice (1977)
• Erich Gamma began cataloging design patterns in
  1991 (Ph.D. thesis)

4
Why Patterns?

• Common design vocabulary
• General object/class intercommunication schemes
  receive concrete, short names
• Documentation and learning aid
• Ease in understanding large systems
• Captured knowledge of good previous solutions
• Promote and standardize good design
• Assist in refactoring (reorganizing) software

5
Example Designing an Editor

• Lets illustrate the design of a WYSIWYG document
  editor called Lexi
• Demonstrate how design patterns work
• Demonstrate nine design patterns
• CS342 covers patterns in more detail
• This example comes from Design Patterns Elements
  of Reusable Object-Oriented Software by Erich
  Gamma et al.

6
Lexi Document Structure

• Documents are just an arrangement of characters
  and graphics primitives
• Authors tend to view documents as total physical
  structure (lines, columns, tables)
• Each of these elements has its own set of
  substructures, creating part-whole hierarchies
• In order to manipulate these structures
  uniformly, use recursive composition (tree-like
  object hierarchy)

7
The Composite Pattern

• Transparently and uniformly manipulate part-whole
  hierarchies of objects
• Interfaces of the objects must be compatible
• Use an inheritance hierarchy to specify what
  behaviors are allowed subclasses specify
  appropriate behaviors for themselves and yet
  specialize for their own substructures
• Meaningful behavior of an object by itself AND as
  part of a larger group
• Java GUI libraries have Composite structure

8
Example Graphics Structure
9
From Primitives to Documents

• Objects that make up documents are represented in
  a part-whole hierarchy
• Documents are built from these parts, with extra
  formatting / structural information
• WYSIWYG editor -- need an automatic formatting
  algorithm with good response
• Best choice for the job may not be apparent at
  compile-time, or may change with conditions

10
The Strategy Pattern

• Define a family of algorithms, encapsulate each
  one, and make them interchangeable
• The algorithm may vary independently from clients
  that use it
• In general, make the algorithm an abstract class
  or interface, and have several different
  implementations to choose from
• The data on which the algorithm is to operate may
  need to be privately exposed to it

11
Sample Formatting Design

• e.g. Line break algorithms
• Simple Put as many things as will fit on a
  line, then break
• TeX Try to optimize line breaks for best
  appearance (e.g. simple strategy may cause an
  ugly future line break at a large word)
• Array Select breaks so each line has the same
  number of Graphic elements on it
• Create a Graphic subclass that can plug in
  different line break algorithms

12
Embellishing the UI

• Should be able to add borders, and possibly
  scrollbars, to elements of the Graphics
  part-whole hierarchy
• Do so transparently, without breaking existing
  code
• Uniformly treat graphics with embellishment and
  graphics without it

13
The Decorator Pattern

• Attach more responsibilities dynamically through
  transparent enclosure
• Create a compatibly-interfaced object that
  handles the embellishments and delegates work to
  the embellished object before or after the
  embellishments are applied
• Prevents combinatorial explosion of possible
  embellishment combinations
• Inheritance ensures compatible interfaces
• Composition allows delegation

14
Example of Border Addition
15
Multiple Look and Feel

• Windows, UNIX, X-Windows, etc. all have a
  different look and operation of their windowing
  systems
• Would be wise to make it as easy as possible to
  support cross-platform look and feel if
  portability is a major goal
• Possible need to customize look and feel at
  runtime

16
The Abstract Factory Pattern

• Provide an interface for creating families of
  related or dependent objects without specifying
  their concrete classes
• Requires an interface definition for both the
  creating object and the object to be manufactured
  by the factory
• Both the factory and the created objects may be
  of different concrete classes

17
Adding Cross-Platform Buttons
18
Supporting Multiple Windowing Systems

• Window systems (Windows, Mac, X) are generally
  interface-incompatible, although they perform
  many of the same activities
• Inheritance is difficult to use in this case
  possible combinatorial explosion of specific
  window classes, especially if Decorator used
• In order to support multiple windowing systems,
  we need to encapsulate their divergent interfaces
  into a single object type with a unified interface

19
The Bridge Pattern

• Decouple an abstraction from its implementation
  so that the two can vary independently
• Specify a common bridge interface to the desired
  abstraction
• Implementations need not be interface-compatible,
  but they do need to be easily wrapped in the
  bridge interface

20
Adding Multiple Windowing System Support
21
User Operations

• Identical navigation through an application can
  occur via different, unrelated sources
• Both a pull-down menu and a shortcut button on
  the screen might do, for example, an editing
  operation or a page down operation
• Simple methods wont do hard to undo/redo, hard
  to extend, tightly tied to details of the
  operation which may be invisible to that method
• Again, combinatorial explosion of possible
  extensions to existing classes to support
  navigation need a simple mechanism

22
The Command Pattern

• Encapsulate requests as command objects
• Lets you parameterize classes with different
  requests
• Lets you track requests
• Lets you support undoable operations
• Commands are constructed with a unified interface
  and contain enough knowledge (e.g. reference to
  target object and/or access to its data) to
  execute the desired request

23
User Request Hierarchy
24
Document Analysis

• Need a simple way to traverse the document
  structure without knowledge of its representation
  (no assumptions about graphics present)
• For each kind of analysis, need a simple way to
  generate the graphics that should be checked and
  separate them from those that should not (e.g.
  images, figures are not checked during a spell
  check)

25
The Iterator Pattern

• Provides a way to access the elements of an
  aggregate object sequentially without exposing
  its underlying representation
• Take responsibility for access and traversal out
  of the list object and put it into an iterator
  object whose interface consists of all desired
  traversal operations
• Objects have responsibility for creating their
  own iterators usually done via a factory method

26
The Factory Method Pattern

• Defines an interface for creating an object, but
  lets subclasses decide which class to instantiate
• Used if a class cannot anticipate the class of
  objects it must create, or wants its subclasses
  to specify the objects it creates

27
Graphics Iterators with a Factory Method
28
Performing Analysis with Iterators and Visitors

• Iterators give sequential order of the elements
  in a document, but contain no analytical
  capabilities (unified interface)
• Visitors group related operations together
• In spell checking, a visitor might take Graphics
  from a documents Iterator one by one and append
  any characters to an internal buffer, ignoring
  all other Graphics
• Once a word is assembled, do a dictionary check
  for the word

29
The Visitor Pattern

• Represent an operation to be performed on the
  elements of an object structure
• Lets you define a new operation without changing
  the classes of the elements on which it operates
• Key is that every element of the structure must
  be visitable there is a uniform interface to
  accept a visitor, but subclasses may define the
  visitation operation differently
• All visitors implement a unified interface

30
Visitors for Textual Analysis
31
When Are Patterns Bad?

• These are design patterns targeted at designing
  reusable software
• Much work must be invested to refactor existing
  software to make use of patterns
• Not worthwhile if reuse is not a concern
• Blind use of a pattern when it does not apply can
  lead to architectural problems
• Can confuse inexperienced developers or designers
  education is the key

32
Current Movements

• More patterns are being identified
• Easy to spot the existence of a pattern
• Hard to describe what its effect is
• AntiPatterns are patterns common to
  failing/troubled software projects
• A design pattern is meant to be used to assist a
  software project
• An AntiPattern is meant to save a software
  project in jeopardy tend to be more pragmatic
  than design-oriented