Software Construction & Design 1
The University of Sydney Page 1
Software Design and
Construction 2
SOFT3202 / COMP9202
Advanced Design Patterns
(GoF)
School of Information Technologies
Dr. Basem Suleiman
The University of Sydney Page 2
Copyright Warning
COMMONWEALTH OF AUSTRALIA
Copyright Regulations 1969
WARNING
This material has been reproduced and communicated to
you by or on behalf of the University of Sydney
pursuant to Part VB of the Copyright Act 1968 (the
Act ).
The material in this communication may be subject
to copyright under the Act. Any further copying or
communication of this material by you may be the
subject of copyrightprotection under
the Act.
Do not remove this notice.
The University of Sydney Page 3
Agenda
GoF Design Patterns
Flyweight
Bridge
Chain of Responsibility
The University of Sydney Page 4
Flyweight Design Pattern
Object Structural
The University of Sydney Page 5
Motivation Text Editor Application
Design of document editor system
Use objects to represents tables/figures
Use object for each character
Discuss benefits and drawbacks ?
The University of Sydney Page 6
Flyweight Motivation
Flexibility at fine granular level uniform
formatting and processing
Support new character set without impacting
other functions (extensibility)
Very high cost (memory)
The University of Sydney Page 7
Motivation Text Editor Application
An object for each letter of the alphabet
Shared object than can be used in multiple contexts simultaneously
What about objects state?
Character code
Character position (coordinates)
Typographic style
Given the sharing aspect, how the above states should be stored?
The University of Sydney Page 8
Motivation Text Editor Application
An object for each letter of the alphabet
Shared object than can be used in multiple contexts simultaneously
What about objects state?
Character code (intrinsic/shared)
Character position (extrinsic/not shared)
Typographic style (extrinsic/not shared)
Given the sharing aspect, how the above states should be stored?
Intrinsic state: shared and thus stored in the shared object
Extrinsic state: cannot be shared as it depends on the context (clients responsibility)
The University of Sydney Page 9
Text Editor Application Flyweight Objects
One shared flyweight object per
character which can appear in
different contexts in the document
structure
The University of Sydney Page 10
Text Editor Application Flyweight Design
The University of Sydney Page 11
Flyweight Pattern
Object structural
Intent:
Use sharing to support large numbers of fine-grained objects efficiently
Applicability:
Large number of objects are used
Storage costs are high
Most object state can be made extrinsic
Many groups of objects may be replaced by relatively few shared objects once
extrinsic state is removed
The application does not depend on object identity
The University of Sydney Page 12
Flyweight Structure
The University of Sydney Page 13
Flyweight Participants & Collaboration
Flyweight (Glyph)
Interface for extrinsic state
ConcereteFlyweight (Charcterer)
Implements Flyweight interface adding intrinsic state
UnsharedConcereteFlyweight (Row, Column)
Make some concrete flyweight subclasses unshared
FlyweightFactory
Creates and manages flyweight objects and ensure proper sharing
Client
Maintains a reference to flyweights
Eunice
https://www.cnblogs.com/vrliym/archive/2010/11/08/1872190.html
The University of Sydney Page 14
FlyweightConsequences
Benefits
Efficiency: save memory at run-time (sharing objects, intrinsic state)
Consistency: centralized objects state
Drawback
Un-time costs to transfer find and/or compute extrinsic stae
All objects are controlled identically
The University of Sydney Page 15
Flyweight Implementation
Extrinsic state and efficient storage
If there are as many different kinds of extrinsic state as there are objects before
sharing, then removing it from shared objects wont reduce storage costs
Managing shared objects
FlyweightFactory objects often use an associative store to let clients look up flyweight of
interests
Sharing implies reference counting or garbage collection to reclaim a flyweights storage
when its no longer needed, especially when number of flyweights is large
The University of Sydney Page 16
Flyweight Related Patterns
Composite
Flyweight often combined with the composite pattern to implement a
hierarchical structure as a graph with shared nodes
Leaf nodes cannot store a pointer to their parent (passed)
State and Strategy Patterns
Flyweight often implement state and strategy objects as flyweights
The University of Sydney Page 17
Bridge
Object Structural
The University of Sydney Page 18
Motivating Scenario
Portable window abstraction in a user interface
toolkit
Abstraction to allow writing applications that
work in different platforms (e.g., Windows, IBM)
Design using inheritance (right diagram)
Good/bad design? Why/Why not?
The University of Sydney Page 19
Motivating Scenario Design with Inheritance
Extend window abstraction to cover
different implementation, BUT:
Implement many classes in the
hierarchy
Strong binding between abstraction
and binding(client code is platform-
dependent)
The University of Sydney Page 20
Better Design using the Bridge
. Bridge
The University of Sydney Page 21
Bridge Pattern (Handle or Body)
Avoid permanent binding between an abstraction and its implementation
Abstractions and their implementations should be extensible
Changes in an abstractions implementation should not impact its client
Large number of classes involved
Split into two class hierarchies (nested generalization)
Share an implementation on multiple objects and make the client unaware of it
The University of Sydney Page 22
Bridge Pattern Participants and Collaboration
.
Client
The University of Sydney Page 23
Bridge Pattern Participants and Collaboration
Abstraction (Window)
Defines the abstractions interface and maintains a reference to an object of type
Implementor
RefinedAbstraction (IconWindow)
Extends the interface defined by Abstraction
Implementor (Windowlmp)
Defines the interface for implementation classes.
The Implementor interface provides only primitive operations, and Abstraction
defines higher-level operations based on these primitives
Concretelmplementor (XWindowImp, PMWindowImp)
Implements the Implement or interface and defines itsconcrete implementation.
Client
Abstraction forwards client requests to its Implementor object.
The University of Sydney Page 24
Bridge Pattern Consequences
Decoupling interface and implementation
Implementation can be configured at run-time
Reduce compile-time dependencies on implementation
Better structured design
Improve extensibility
Abstraction and implementor can be extended independently
Hiding implementation details from clients
Increased complexity!
Two hierarchies to grow and to manage
The University of Sydney Page 25
Bridge Pattern Implementation
One implementor
Abstract implementor class isnt necessary if theres only one implementation
Its still useful when a change in the implementation of a class must not affect its
existing clients
Creating the right implementor object when there is more than one
Abstractions constructor if it knows about all ConcereteImplementor classes
A collection class supports multiple implementations, decide by the collections size
Use linked list for a small collection
Use a hash table for a large collection
Default implementation which can be changed according to usage
The University of Sydney Page 26
Bridge Pattern Related Patterns
Abstract Factory
Can create and configure particular Bridge
Adapter
Aims at making un-related classes work together(after design consideration)
Bridge focuses on making abstraction and implementations vary independently
(during design)
The University of Sydney Page 27
Chain of Responsibility
(CoR)
Object Behavioural
The University of Sydney Page 28
Motivating Scenario GUI with Help
GUI with a help facility where a user gets help information by clicking on it
Help information dependent on the interfaces context (context-sensitive)
Button in dialog box vs. button in a window
Display general help info. About the immediate context in case no specific help
exits
The University of Sydney Page 29
GUI with Help Potential Design
Organize help info. according from the most specific to the most general
Several UI objects, one per help request
Discuss the prose/cons of this design.
The University of Sydney Page 30
GUI with Help Potential Design
It helps to serve different types of help requests
However, the object that ultimately provides the help isnt known explicitly
to the object that initiates the help request (strong coupling)
So, we need a way to decouple the object that initiates the help request
from those that might provide the help information
The University of Sydney Page 31
Better Design Chain of Responsibility (CoR)
Provide multiple objects a chance to handle a request
Pass the request along a chain of objects until one handles it
First object receives the request either handles it or forward it to the next
candidate on the chain, and so on so forth
The request has an implicit receiver as the requester object has no explicit
knowledge of the handler object
The University of Sydney Page 32
Better Design Chain of Responsibility (CoR)
Solution details
User clicks the Print buttons help
(contained in PrintDialog instance)
PrintDialog knows the object it belongs to
The client (request issuer) has no direct
reference to the object that ultimately
realizes it
The University of Sydney Page 33
Better Design Chain of Responsibility (CoR)
How to ensure implicit receiver?
Each object shares common interface for handling requests and accessing its
successors on the chain
Classes that want to handle help
requests can make HelpHandlera
parent
HelpHandlers HandleHelp
forwards the request to the
success by default
Subclasses can override this
operation to provide help under
the right conditions
The University of Sydney Page 34
Chain of Responsibility Pattern
Intent
Avoid coupling the sender of a request to its receiver
It allows more than one object a chance to handle the request
Chain the receiving objects and pass the request along the chain until an object
handles it
Use
More than one object may handle a request, and the handler should be ascertained
dynamically
Hide the receiver (explicitly) when a request should be issued to one of several
objects
The handling behavior should be specified dynamically
The University of Sydney Page 35
CoR Pattern Structure
Class structure
Typical object
structure
The University of Sydney Page 36
CoR Pattern Participants and Collaboration
Handler (HelpHandler)
Defines interface for handling requests
May implement the successor line
ConcreteHandler (PrintButton, PrintDialog)
Handles requests it is responsible for
forwards the request to its successor if it cannot handle it
Client
Initiates a request which will be propagated along the chain until a
ConcereteHandler takes responsibility for handling it
The University of Sydney Page 37
CoR Pattern Consequences
Reduced Coupling
Objects in the chain does not have explicit knowledge about each other
Flexibility in distributing responsibilities among objects
Can add/change responsibilities at run-time
Requests could be unhandled
Theres no guarantee that a request could be handled
The University of Sydney Page 38
CoR Pattern Implementation (1)
Declaring child management operations: which classes declare the child management
operations (add, remove) in the composite class hierarchy:
Define child management interface at the class hierarchys root
Allows treating all components uniformly (transparent)
Clients may add/remove objects from leaves (not safe)
Child management in the composite class
Add/remove objects at the compile-time in statically typed languages (safe)
Leaves and composites have different interfaces (not transparent
Transparency over safety
The University of Sydney Page 39
CoR Pattern Implementation (2)
Child ordering
Ordering on the children of composite is important in some designs
Composites represents parse trees then compound statements can be instances of a
composite whose children must be ordered to reflect the program
Design child access and management interfaces carefully to manage the sequence
(use iterator pattern)
The University of Sydney Page 40
CoR Pattern Related Patterns
Composite
In CoR pattern, a components parent can act as its successor and hence the use of
Composite pattern
The University of Sydney Page 41
References
Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides.
1995. Design Patterns: Elements of Reusable Object-Oriented Software.
Pearson.
OO Design, Online: [https://www.oodesign.com/bridge-pattern.html]
https://www.oodesign.com/bridge-pattern.html
The University of Sydney Page 42
W7 Tutorial: Practical
Exercises/coding
W7 Lecture: Enterprise Design
Patterns
Testing Assignment A2
Reviews
There are no reviews yet.