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 copyright protection 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 object’s 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 object’s 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 (client’s 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
Flyweight Consequences
– 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 won’t 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 flyweight’s storage
when it’s 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 abstraction’s 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 abstraction’s 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 its concrete 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 isn’t necessary if there’s only one implementation
– It’s 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
– Abstraction’s constructor if it knows about all ConcereteImplementor classes
– A collection class supports multiple implementations, decide by the collection’s 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 interface’s 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 isn’t 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” button’s 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
– HelpHandler’s 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
– There’s 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 hierarchy’s 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 component’s 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