Introduction to Design Patterns

1
Introduction to Design Patterns
2
Outline

• Introduction and Background
• Common and Simple Design Patterns
• Identification and Application of Design Patterns
• Advanced Design Patterns
• Exercises

3
Goal of Presentation

• Provide a working introduction to
• Patterns
• Pattern Systems
• Using pattern resources (web, books, etc.)
• Identifying and sharing domain specific patterns
• Use of patterns in Java

4
Pattern Definition

• A "pattern" is ...
• An abstraction from a concrete form which keeps
  recurring in specific, non-arbitrary contexts.
  generic definition
• A recurring solution to a common problem in a
  given context and system of forces. Alexander
• A named "nugget" of instructive insight,
  conveying the essence of a proven solution to a
  recurring problem in a given context amidst
  competing concerns.
• A successfully recurring "best practice" that has
  proven itself in the "trenches".
• A literary format for capturing the wisdom and
  experience of expert designers, and communicating
  it to novices

5
What are software patterns?

• Trendy
• Recent "hot-topic", OOD buzzword, lots of "hype"
  
• Literary
• Form of software engineering problem-solving
  documentation
• Pragmatic
• Describe practical solutions to "real world"
  problems
• Recurring
• Identify good design structures which recur in
  practice
• Generative
• Show how/when to apply the solution, and generate
  the desired design structure
• Emergent
• Larger solutions emerge indirectly from applying
  patterns in succession, and in concert together

6
Example

• Name Singleton
• Category Object Creation
• Intent
• Ensure a class only has one instance and provide
  global point of access
• Motivation
• Its important for some classes to have exactly
  one instance. For example, there typically is
  only one instance of each file system class in an
  operating system.

Singleton
-uniqueInstance
singletonData
-Instance()
SingletonOperation()
return unique
GetSingletonData()
Instance
7
Example Use of Singleton Metadata

• Metadata objects
• Data that describes other data
• Not of the same class as the objects they
  describe
• Cake recipe is not a cake, but describes how to
  make
• Form of object-based classification
• Most OO languages have metadata class objects
• What came first, the class or the object?
• Used when there are
• Potentially an infinite number of types
• Models of cars, recipes
• Lots of component based semantic dependencies
• Account types, calling plans

• Example
• Catalog Entry is very different than Warehouse
  Item
• but they have analogous structure (e.g.
  Relationship of parts)
• Do not want to use inheritance to model analogies
• Problems when analogy breaks down
• Will end up overriding most of the parents
  methods

8
Software Patterns are ...

• Recurring solutions to common problems of design
• Practical/concrete solutions to real world
  problems
• Context specific
• "Best-fits" for the given set of
  concerns/trade-offs
• "Old hat" to seasoned professionals and domain
  experts
• A literary form for documenting best practices
• A shared vocabulary for problem-solving
  discussions
• An effective means of (re)using, sharing, and
  building upon existing wisdom/experience/expertise
  
• Massively hyped!

9
History of Patterns

• Writings of architect Christopher Alexander
  (coined this use of the term "pattern" ca.
  1977-1979)
• Documentation of best practices and handbooks for
  engineering and architecture
• Literate programming (Don Knuth), ca. 1984
• Kent Beck and Ward Cunningham, Textronix,
  OOPSLA'87 (used Alexander's "pattern" ideas for
  Smalltalk GUI design)
• Erich Gamma, Ph. D. thesis, 1988-1991
• James Coplien, Advanced C Idioms book,
  1989-1991
• Gamma, Helm, Johnson, Vlissides ("Gang of Four")
• Object-Oriented Design Patterns book, 1991-1994
• PLoP Conferences and books, 1994-present

10
Kinds of Software Patterns

• Design Patterns (software design often
  object-oriented)
• Fundamental
• Creational
• Behavioral
• Structural
• Analysis Patterns (recurring reusable analysis
  models)
• Architectural Patterns (between analysis and
  design recurring implementation structures)
• Domain-specific - Any domain you can think of!

11
Defining A Pattern

• No standard form yet
• PLoP conference is working on it
• Common Formats
• Alexandrian Form
• used Alexander's work
• GoF Form
• Canonical Form

12
Essential Elements of a Pattern

• Name
• A meaningful "conceptual handle" for discussion
• Context
• Tells how the problem occurs / when the solution
  works
• Problem
• Statement of the problem / intent of the solution
  
• Forces
• Trade-offs, goalsconstraints, motivating
  factors/concerns
• Tells why the problem is difficult
• Solution
• Tells how to generate the solution
• The solution structure, its participants
  collaborations

13
Essential Elements of a Pattern

• Examples (optional)
• Resulting Context
• Describes the end result, benefits and
  consequences
• Shows how the forces were balanced/traded-off
• Tells how the solution works out
• Rationale (optional)
• Underlying principles/heuristics justifying the
  solution
• Tells underpinnings of why the solution works out
  
• Related Patterns
• Patterns which are similar, or which may
  precede/follow this one
• Known Uses
• 3 or more independent instances of "real world"
  success

14
GoF Form

• Pattern Name (Scope, Purpose)
• Name convey essence of pattern succinctly
• Intent
• Short statement answering questions
• What does the design pattern do?
• What is its rationale and intent?
• What particular design issue or problem does it
  address?

15
GoF Form (cont.)

• Also Known As
• Other well-known names for the pattern, if any
• Motivation
• Scenario that illustrates
• design problem
• how class object structures in pattern solve
  problem
• Helps understanding the more abstract description
  that follows

16
GoF Form (cont.)

• Applicability
• What situations can applied pattern?
• Examples of poor designs that pattern addresses?
• How to recognize situations?
• An applicable situation

17
GoF Form (cont.)

• Structure
• Participants
• Describe for each Class/object participating in
  pattern
• Participant Name
• Responsibility
• Collaborations
• How the participants collaborate
• Relations

18
GoF Form (cont.)

• Consequences
• How pattern support its objectives?
• Trade-offs results of using pattern?
• What aspects of system structure can you vary
  independently?

19
GoF Form (cont.)

• Implementation
• Are there language-specific issues?
• Pitfalls
• Hints
• Techniques

20
GoF Form (cont.)

• Sample Code Usage
• Code fragments illustrating implementation
• Known Uses
• Examples of pattern found in real systems.

21
GoF Form (cont.)

• Related Patterns
• What design patterns are closely related to this
  one?
• What are the important differences?
• With which other patterns should this one be
  used?

22
GoF Form Example Singleton

• Name Singleton
• Intent ensure a class has only one instance
• Motivation It is important for some classes to
  have exactly one instance, like one file system,
  one window manager
• Applicability
• when there must be exactly one instance of a
  class
• when the sole instance should be extensible by
  subclassing
• Structure shown earlier as a class diagram

23
GoF Form Example Singleton (cont.)

• Participants
• defines an Instance operation that lets clients
  access unique instance
• Collaborations
• - clients access a Singleton instance solely
  through Singletons Instance operation
• Consequences
• -controlled access to sole instance
• -reduced name space
• -permits refinement of operations and
  representation
• Implementation discussing implementation issues
• Sample Code class/interface descriptions in a
  specific language
• Known Uses InterViews user interface toolkit

24
Implementing MVC
Edward Colbert Missing example
25
Why Patterns?

• Software Patterns help us because they
• Solve "real world" problems
• Capture domain expertise
• Document design decisions and rationale
• Reuse wisdom and experience of master
  practitioners
• Form shared vocabulary for problem-solving
  discussion
• Show more than just solution
• context (when and where)
• forces (trade-off alternatives, misfits,
  goalsconstraints)
• resolution (how and why solution balances forces)

26
Abuse of Patterns

• Beware of unnecessary generalization
• Utility/Generality tradeoff
• Obscuring structure
• Performance overhead
• Effort required to identify and adapt patterns
  (value/effort)
• Tricky platform dependencies

27
Abuse (cont.)

• Software Patterns are not ...
• Panacea or "silver bullet"
• Little inspiration, mostly perspiration
• Restricted to software design or Object-Oriented
  design
• Untested ideas/theories or new inventions
• Solutions that have worked only once
• Any old thing written-up in pattern format
• Abstract principles or heuristics
• Universally applicable for all contexts

28
Ubiquitous Problems and Simple Design Patterns
29
Problems of Redundancy

• Problem Many elements in a system will share
  similar structures and/or functionality
• Common solutions
• Subroutines and modules
• Inheritance
• Define new structure and/or functionality then
  define a static relationship with parents to
  use theirs
• Implementation (operations and attributes)
• Interface (sub-type)
• Composition
• Combine common parts then define new structure
  and/or functionality as necessary

30
Object Interfaces and Types

• Interface to an object
• Set of all operation signatures
• Note this is not the same as a java interface
• Type
• Named set of particular operation signatures
• Type that specializes another type is called
  subtype
• Helps reduce redundancy by enabling
• Dynamic binding
• Known types allow runtime mapping of requests to
  an objects operations
• Polymorphism
• Objects of same type can be substituted at runtime

31
Inheritance

• Class (of an object)
• Defines interface and implementation
• An object instantiated from a Class
• A subclass has all the interface and
  implementation of particular other Classes
• The other classes are parents of the subclass
• The subclass is said to inherit from its
  parents
• An abstract class is never instantiated
• mainly used to define an interface
• A leaf class is never subclassed
• A concrete class is anything else

32
Interface vs. Inheritance

• Class (stateoperations) vs. type (interface)
• Proper inheritance
• derived classes should share same interfaces
• Add or override, not hide parent operations
• Heuristic inherit for subtype only!
• Interface defined by abstract classes allow
  clients to remain unaware of internal details
  (reduces implementation dependencies)
• Principle 1 Program to an INTERFACE not
  implementation!
• Creational patterns ensure this principle
• Singleton, Abstract Factory, Builder, Factory,
  etc.

33
Fundamental Design Patterns

• Delegation Grand
• Interface Grand
• Immutable Grand
• Relational Objects ???
• We will also introduce a Structural Pattern
• Composite GoF

34
Delegation Grand

• A relationship between objects where one object
  forwards certain method calls to another object
  (delegate)
• Powerful design/reuse technique

35
Designing Bi-directional Relationships

• Issues
• Where are jobs? (e.g. where does salary
  live?)
• How does the Company find an employee?
• Would you create Employee and Employer subclasses?

36
Relational Attributes and Selectors
Solution add Relational objects and delegate!
employment
Person
Company
salary
theCompany
myJob
jobSlot
employer
Person
Company
salary
0..1
0..1
1
1
Relational objects
myEmployee
employees
employeeSlot
1..1
1..1
Person
Company
Employee
1..
1..
employee
37
Multi-Way Relationships
Person
reference librarian
Library
Reference
Material

• How do you handle three simultaneously related
  components?
• Reference Material housed in a Library managed
  by a reference librarian and all other
  permutations and combinations
• Inheritance is no help here
• This is a very common analysis problem,
  fortunately there is usually a nice solution!

38
Relational Component
Person
reference librarian
Library
Reference desk
Reference
material

• Introduce a Relational Component (to be designed
  with appropriate objects later as needed) to
  manage the relationships.
• Usually the Relational Component will have a
  reasonable counterpart in the domain
• Introduce a specialized object if no counterpart
  in the domain exists

39
Inheritance vs. Delegation

• Inheritance is inappropriate for many situations,
  supports is a kind of relationship
• creates strong, static coupling between class and
  subclasses
• Delegation gives run time flexibility, although
  less structured, harder to understand

40
Delegation

• Use when you dont have static reln between
  classes, e.g.. Role management
• Instead of inheriting window from rectangle
  (window is not a rectangle), have the shape
  related methods delegated to rectangle (shape)
  object
• Used heavily in Java, for example Javas event
  model
• EventSources usually do nothing with an event
  and pass it on to EventListeners to process
• Most all design patterns use delegation
• Heavy use in State, Strategy, Visitor, Proxy,
  Decorator

41
Designing Roles with Delegation
42
Component Roles
Person
board member
Hancock Virtual
Person
Museum
patron
Person
curator
43
Example Inheritance Solution
Hancock VirtualMuseum
Person
Patron
BoardMember
Curator
44
Example Inheritance Solution
Hancock VirtualMuseum
Person
Patron
BoardMember
Curator
What if a Patron becomes a Board Member? .etc.
45
Designing Object Roles
Person
Person
Person
aPatronRole
theCuratorRole
aBoardMemberRole
Hancock Virtual
Museum
46
Example Inheritance Hierarchy
PersonRole
Hancock VirtualMuseum
Person
PatronRole
BoardMemberRole
CuratorRole
47
Designing Multi-target Roles
aPatronRole
Museum
HancockVirtual
Museum
aPatronRole
Person
.
Implies re-classification of Patron Role
48
Multi-role Target
selector
theDirectorRole
selected from
Hancock Virtual
Person
aBoardMemberRole
Museum
49
Designing Components
Person
50
Inheritance vs. Composition

• White-box reuse (subclassing) Uses visible
  implementations
• easy to use/modify
• static, tends to breaks encapsulation, limited
  flexibility
• Black-box reuse (composition) Uses hidden
  implementations
• dynamic, less dependencies
• more objects, complex relationships and
  dependencies
• Principle 2 Favor composition over inheritance

51
Example Use of Compositions Component Based
Subtyping
52
Design PatternsExpanding Classifications
CreditCard
Corporate CC
PersonalCC
PlatinumPCC
StandardCCC
PlatinumCCC
GoldCCC
StandardPCC
GoldPCC
53
Expanding Classifications Have Redundancy
Repetitive Layer
54
Component Based Sub-typing
CreditCard
Corporate
Personal
55
CBS Class and Instance Diagrams
Gold
cardType
56
Composite GoF

• Designed to implement collection of classes
• Use to
• build part-whole hierarchies or
• construct data representation of trees
• when you want your clients to ignore the
  difference between compositions of objects and
  individual objects

57
Composite Pattern Example

1
58
Composite Pattern General Form

1
59
Composite Pattern Participants

• AbstractComponent abstract superclass
• ConcreteComponent1,2 leaves of tree
• AbstractComposite abstract superclass of all
  composite objects that participate in the
  Composite pattern
• ConcreteComposite1,2 composite objects that use
  other instances of AbstractComponent

60
Reasons/Consequences

• Defines class hierarchies
• Simple Clients
• Doesnt know/care whether dealing with leaf or
  composite class
• Uniform treatment of composite individual
  object
• Easier to add new components
• New composites or leaves work automatically
• Can make design over general
• Sometimes want a composite to have only certain
  components
• Need run-time checks
• Sharing components to reduce space when there is
  more than one parent is difficult
• Issue which classes should declare operations
  for component management

61
Known Uses/ Related Patterns

• Almost all OO systems
• View class of MVC
• Component/Container class of java.awt
• Decorator,Flyweight, Iterator, Visitor

62
Creational Patterns

• Factory GoF
• Abstract FactoryGoF
• Builder GoF
• Prototype GoF
• Singleton GoF
• Object Pool Grand

63
Factory GoF

• Define interface for creating object, let
  subclasses decide which class to instantiate.
• Reusable class delegates this choice, and refers
  to new object by interface

64
Factory Pattern Example
65
Factory Pattern General Form
66
Factory Pattern Participants

• Product abstract superclass of objects produced
  by the pattern
• Concrete Product subclasses of product
• CreationRequestor application independent class
  creating app specific classes
• FactoryIF application independent interface,
  creation method takes args to deduce the class to
  instantiate
• Factory application specific class that has a
  method to create Concrete Products

67
Reasons/Consequences

• Set of subclasses to be instantiated may be
  dynamic as new classes are available
• Class must create objects without knowing what
  subclasses are there
• Creation requestor class independent of class
  of created concrete product objects
• Subclasses of product class may change
  dynamically

68
Known Uses / Related Patterns

• JAVA API URLConnection, getContent method
  returns different image files, docs..
• EJB Creation Model
• Toolkits, frameworks Unidraw
• Abstract Factory, Template, Prototype

69
Abstract Factory GoF

• One level of abstraction higher than Factory
• Creates families of related classes
• When your system needs to support multiple UI for
  Windows, Mac, Motif

70
Abstract Factory Example
Architecture Toolkit
getFactory()
createCPU()
createMMU()
EmberToolkit
EnginolaToolkit
createCPU()
createCPU()
Uses
createMMU()
createMMU()
1
1
1
1
1
1
1
1
Creates
Creates
Creates
Creates








Client
EmberCPU
EmberMMU
EnginolaCPU
EnginolaMMU
1
1
1
Uses
Uses


MMU


CPU
71
Abstract Factory General Form
AbstractFactory
getFactory()
createA()
createB()
ConcreteFactory1
ConcreteFactory2
createA()
createA()
Uses
createB()
createB()
1
1
1
1
1
1
1
1
Creates
Creates
Creates
Creates








Client
Product2WidgetA
Product1WidgetA
Product1WidgetB
Product2WidgetB
1
1
1
1
Uses
Uses



WidgetB
WidgetA
72
Abstract Factory Participants

• Client only know about abstract widgets
• AbstractFactory define abstract methods for
  concrete widget instances
• ConcreteFactory1,2 implement methods to create
  instances of concrete widgets
• Widget A,B abstract widgets
• Product1WidgetA,..concrete widgets that
  correspond to a feature of a product

73
Reasons/ Consequences

• A system independent of how its products are
  created/composed/represented
• A system configurable with one of multiple
  families of products
• You want to reveal only interfaces of a class
  library of products
• It isolates concrete classes
• Makes exchanging product families easy
• Promotes consistency among products
• Supporting new kinds might be difficult

74
Known Uses/ Related Patterns

• JAVA API, awt toolkit
• ET, OO application framework in C for
  portability
• Factory, Prototype, Singleton

75
Structural Patterns

• Adapter GoF
• Bridge GoF
• Composite GoF (already covered)
• Decorator GoF
• Façade GoF
• Flyweight GoF
• Proxy GoF

76
Behavioral Patterns

• Chain of Responsibility GoF
• Command GoF
• Interpreter GoF
• Iterator GoF
• Mediator GoF
• Memento GoF
• Observer GoF
• State GoF
• Strategy GoF
• Template GoF
• Visitor GoF

77
Observer GoF

• Define dependency between objects so that when
  one object changes state, all its dependents are
  notified

78
Observer Pattern Example
ltltInterfacegtgt
SecurityObserver
SecurityNotifier
ALARMint1 frozen
LOW_POWERint2 frozen
addObserver( SecurityObserver)
Notifies
0..
DIAGNOSTICint3 frozen
removeObserver( SecurityObserver)
notify(device int, event int)
SecurityClient
SecurityAdapter
SecurityMonitor
Notifies
1
1
1
1
79
Observer Pattern General Form
80
Observer Pattern Participants

• ObserverIF defines notify or update
• Observer receive state change notifications
• ObservableIF defines two methods that allow
  Observer objects to un/register to receive
  notifications
• Observable responsible for managing the
  registration of ObserverIF objects, delivering
  the notifications. It delegates those
  responsibilites to Multicaster object,
• Multicaster delivers notifications to ObserverIF
  objects on behalf of an Observable Object

81
Reasons/ Consequences

• When change in one object requires changing
  others
• When object should be able to notify other
  objects without knowing who they are
• Support for broadcast communication
• Delivering notifications can take long time if
  there are a lot of objects to deliver
  notifications to
• Watch out for cyclic dependencies, dangling
  references to deleted subjects

82
Known Uses/ Related Patterns

• Javas delegation even model as a specialized
  form, eventlisteners
• Adapter, Delegation, Mediator

83
Strategy GoF

• Encapsulate a family of related algorithms,
  make them interchangeable, provide a way to
  choose the most appropriate one

84
Strategy Pattern Example
85
Strategy Pattern General Form
AbstractStrategy
Uses
Client
operation()
0..1
1
1
0..1
ConcreteStrategy1
ConcreteStrategy2
86
Strategy Pattern Participants

• Client delegates the operation to an abstract
  class or interface
• AbstractStrategy a way to access the operation
  encapsulated by its subclasses
• ConcreteStrategy1,2 alternative implementation
  of the operation

87
Reasons / Consequences

• You need different variants of algorithm
• Many related classes differ only in their
  behavior
• Eliminates conditional statements
• Provide a choice of implementations
• Communication overhead between Strategy and
  Context
• Increased number of objects

88
Known Uses / Related Patterns

• Borlands ObjectWindows
• ET and Interviews use this pattern for line
  breaking algorithms
• Flyweight

89
Back to our EJB Pet Store

• Models use Strategy
• Ex ModelManager.java
• a single point of access to all Model objects.
  (OrderModel.java, CartModel.java, etc.)
• Views use Composite, Facade
• Ex template.jsp (master template)
• RequestProcessor.java
• Customer.java
• Controllers use Observer, Proxy
• Ex MainServlet.java
• ShoppingClientControllerEJB.java

90
Identification Application of Design Patterns
91
Finding Appropriate Objects

• Decomposing system into objects
• Many factors
• Granularity, dependency, performance, evolution,
  ...
• Many techniques
• Challenge mapping different paradigms
  efficiently
• Design Patterns help identify less-obvious
  abstractions objects
• e.g. ones that dont occur in nature (domain)
  but help achieve flexible design

92
System Factoring
Edward Colbert What goes hear?
93
GoF Pattern Relationships
94
Design for Change

• Creating an object by specifying a class
  explicitly (Abstract Factory, Factory, Prototype)
• Dependence on specific operations (Command)
• HW/SW platform ,Object representation dependence
  (Abstract Factory, Bridge, Memento, Proxy)
• Algorithmic dependencies (Builder, Iterator,
  Strategy, Template, Visitor)
• Tight coupling (Abstract Factory, Bridge,
  Command, Façade, Observer)
• Extending functionality by subclassing (Bridge,
  Composite, Decorator, Observer)
• Inability to alter classes conveniently (Adapter,
  Decorator, Visitor)

95
Example MVCA
Edward Colbert Hows different from p25?
96
Model-View
view
model
97
Model-Controller-View
98
Model-Controller-Association-View
view
association
controller
model
99
A Good Pattern

• Cope says
• Solves a problem
• not just abstract principles or strategies
• Is a proven concept
• has a track record
• not just theories or speculation
• Isnt obvious
• generate a solution indirectly
• not from first principles
• Describes a relationship
• not just classes or modules
• but complete system structures mechanisms
• Has a significant human component
• appeal to aesthetics utility
• elegant
• Small interface, large accessible, cohesive,
  coherent information

100
Domain Specific Design Patterns
101
Compiling a Repository of Patterns

• TO DO
• -Pattern Name and Classification (short,
  meaningful name)
• -Problem (description of problem context, goals,
  constraints that occur, guidance in recognizing
  that pattern)
• -Solution (participants, their structures and
  collaborations, sample code optional)
• -Consequences (results, tradeoffs, Variations
  and language-dependent alternatives
• -Known Uses (real system examples)
• -Contribution (a popular repository WikiWikiWeb
  http//www.c2.com/cgi/wiki)
• NOT TO DO
• Dont make up patterns (use successfully at
  least 3 times before sharing)

102
Pattern Resources Internet

• A Pattern Language Towns, Buildings,
  Construction (APL), Christopher Alexander Oxford
  University Press, 1977
• The Timeless Way of Building (TTWoB), Christopher
  Alexander Oxford University Press, 1979
• Design Patterns Elements of Reusable
  Object-Oriented Software (GoF), Gamma, Helm,
  Johnson, Vlissides Addison-Wesley, 1994
• Pattern-Oriented Software Architecture A System
  of Patterns (POSA), Buschmann, Meunier, Rohnert,
  Sommerlad, Stal Wiley and Sons, 1996
• Pattern Languages of Program Design (PLoPD1),
  Coplien and Schmidt (editors) Addison-Wesley,
  1995
• Analysis Patterns Reusable Object Models, Martin
  Fowler Addison-Wesley, 1996
• Pattern Languages of Program Design 2 (PLoPD2),
  Vlissides, Coplien, and Kerth (editors)
  Addison-Wesley, 1996
• Pattern Languages of Program Design 3 (PLoPD2),
  Martin, Riehle, and Buschmann (editors)
  Addison-Wesley, 1997
• Object Models Strategies, Patterns,
  Applications, Peter Coad with David North Mark
  Mayfield Prentice Hall, 1995

103
Pattern Resources Internet

• Patterns Home Page, http//www.hillside.net/patter
  ns/
• Patterns Discussion FAQ, http//g.oswego.edu/dl/pd
  -FAQ/pd-FAQ.html
• Ward Cunningham's WikiWikiWeb, http//c2.com/cgi/w
  iki?WelcomeVisitors
• Portland Pattern Repository, http//www.c2.com/pp/
  
• AGCS Patterns Page, http//www.agcs.com/patterns/
  
• Jim Coplien's OrganizationPatterns Front Page (a
  WikiWikiWeb work-alike), http//www.www.bell-labs.
  com/cgi-user/OrgPatterns/OrgPatterns
• Patterns Mailing Lists, http//www.hillside.net/pa
  tterns/Lists.html
• Cetus Links Patterns, http//www.objenv.com/cetus
  /oo_patterns.html
• Brad's Pattern Links, http//www.enteract.com/bra
  dapp/links/sw-pats.html
• Brad's Patterns Intro, http//www.enteract.com/br
  adapp/docs/patterns-intro.html
• Luke Hohmann's Patterns Intro, http//members.aol.
  com/lhohmann/papers.htm
• Doug Lea's OOD Patterns Intro, http//gee.cs.osweg
  o.edu/dl/ca/ca/ca.html

104
Advanced Design Patterns
105
Pet Store Design Patterns

• Batch Session Bean Efficiently update multiple
  server-side objects
• Bimodal Data AccessQuickly access read-only
  lists of objects, while maintaing consistent,
  transactional access to individual objects
• Data Access Object (DAO)Provide flexible,
  extensible access to data and other resources
• Front Component Simplify implementation and
  maintenance of user interface presentation and
  workflow
• Model View Controller (MVC) Facilitate
  maintenance, extensibility, flexibility, and
  encapsulation by decoupling software layers from
  one another.
• Paged List Access remote collections in a
  network-efficient way
• Session Entity Façade Provide a single API to a
  collection of enterprise beans
• Value Object Reduce network traffic and improve
  response time for access to coarse-grained,
  read-only data

106
More on our EJB Pet Store
Edward Colbert What?
107
Visitor

• Represent an operation to be performed on the
  elements of an object structure
• Use it when
• Many unrelated operations need to be performed on
  objects in an object structure
• The object structure is composed of objects that
  belong to different classes
• The types of objects in the structure are
  consistent and predictable

108
Façade

• Provide a unified interface to a set of
  interfaces in a subsystem
• Use it when you want to
• provide a simple interface to a complex system
• simplify client classes
• layer your subsystems

109
Memento

• Capture and externalize an objects internal
  state so that the object can be restored to this
  state later
• Use it when you want to
• save a snapshot of an objects state

110
Exercises