Lecture 12
The University of 1
Copyright By PowCoder代写 加微信 powcoder
SOFT2201/COMP9201:
Software Design and
Construction 1
Singleton, Decorator, and
School of Computer Science
The University of 2
Copyright warning
COMMONWEALTH OF AUSTRALIA
Copyright Regulations 1969
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
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
Do not remove this notice.
The University of 3
– Creational Design Pattern
– Singleton
– Structural Design Pattern
– Decorator and Façade
The University of 4
Object Creational
The University of 5
Creational Patterns (GoF)
Pattern Name Description
Factory Method Define an interface for creating an object, but let sub-class decide which class to
instantiate (class instantiation deferred to subclasses)
Builder Separate the construction of a complex object from its representation so that the same
construction process can create different representations
Prototype Specify the kinds of objects to create using a prototype instance, and create new
objects by copying this prototype
a class only has one instance, and provide global point of access to it
The University of 6
Motivated Scenario
– Suppose you have finished your assignment report in your
computer and would like to print it out.
– The first time you click on “print”, it pops up a printing set up window
– The second time you click on “print” without closing the previous printing
window, what do we expect to happen?
The University of 7
– Ensure a class only has one instance, and provide a global point of access to it
– Motivation
– Make the class itself responsible for keeping track of its sole instance (intercept
requests to create new objects and provide a way to access its instance)
The University of 8
– Structure
– Participants
– Defines an instance() operation that lets clients access its unique instance.
instance() is a class operation
– May be responsible for creating its own unique instance
The University of 9
– Collaboration
– Clients access a Singleton instance solely through Singleton’s instance()
operation.
– Applicability
– There must be exactly one instance of a class, and it must be accessible
to clients from a well-known access point
– The sole instance should be extensible by subclassing, and clients should
be able to use an extended instance without modifying their code
The University of 10
public class Singleton {
private static Singleton instance = null;
// Private constructor to prevent direct
initialisation.
private Singleton() {
public static Singleton getInstance() {
if (instance == null) {
instance = new Singleton();
return instance;
public class Client {
Singleton single = Singleton.getInstance();
The University of 11
public class ConfigurationReader {
private static ConfigurationReader instance = null;
private ConfigurationReader() { }
public static ConfigurationReader getInstance() {
if (instance == null) {
instance = new ConfigurationReader();
return instance;
public class Client {
public boolean doStuff() {
ConfigurationReader theOneAndOnlyConfigurationFileReader = ConfigurationReader.getInstance();
The University of 12
public class ConfigurationReader2 {
private static ConfigurationReader2 instance = null;
private ConfigurationReader2() { }
public static ConfigurationReader2 getInstance() {
if (instance == null) {
instance = new ConfigurationReader2();
return instance;
public class Client {
public boolean doStuff() {
ConfigurationReader theOneAndOnlyConfigurationFileReader = ConfigurationReader.getInstance();
ConfigurationReader2 theOtherConfigurationFileReader = ConfigurationReader2.getInstance();
Do you really always want
one specific instance of one
specific class?
The University of 13
public class ConfigurationReader {
public ConfigurationReader() { }
public class Client {
// Explicit dependency in interface.
// The ‘single’ instance is passed around by reference
public boolean doStuff(ConfigurationReader configurationReader) {
The University of 14
Decorator Pattern
Object Structural
The University of 15
Structural Patterns (GoF)
Pattern Name Description
Adapter Allow classes of incompatible interfaces to work together. Convert the interface
of a class into another interface clients expect.
Decorator Attach additional responsibilities to an object dynamically (flexible
alternative to subclassing for extending functionality)
Façade Provides a unified interface to a set of interfaces in a subsystem. Defines a
higher-level interface that simplifies subsystem use.
The University of 16
Motivated Scenario
– Suppose you are shopping in a famous store, which has a
virtual clothing try on application.
• T-Shirts, Trousers and Sneakers
• Suit and Leather Shoes
The University of 17
Motivated Scenario
Client Perspective:
Question: I also want to try on Dress and Boots. What will happen here?
The University of 18
Decorator Pattern
– Attach additional responsibilities to an object dynamically. Decorators provide a
flexible alternative to sub-classing for extending functionality
The University of 19
Decorator – Structure
The University of 20
Decorator – Participants
– Component
– Defines the interface for objects that can have responsibilities added to them
dynamically
– ConcreteComponent
– Defines an object to which additional responsibilities can be attached
– Decorator
– Maintains a reference to a Component object and defines an interface that
conforms to Component’s interface.
– ConcreteDecorator
– Adds responsibilities to the component
The University of 21
Revisit the Motivated Example
The University of 22
Revisit the Motivated Example
The University of 23
Revisit the Motivated Example
Client Perspective
Question 1:
I also want to try on Dress and Boots.
What will happen here?
Question 2:
This system opens to Men and Baby.
What will happen here?
The University of 27
Decorator Pattern – Why Not Inheritance?
– We want to add responsibilities to individual objects, not an entire class
– E.g., A GUI toolkit should let you add properties like borders or
behaviors like scrolling to any user interface component
– Is adding responsibilities using inheritance a good design? For example,
inheriting a border class puts a border every subclass instance
– Why, why not?
The University of 28
Decorator Pattern – Why Not Inheritance?
– Adding responsibilities using inheritance restricts runtime change, and
requires an implementation for every decoration.
– This design is inflexible
• The choice of border is made statically; a client cannot control how
and when to decorate the component with a border
• More flexible design is to enclose the component in another object
that adds the border
The University of 29
Decorator Pattern – Text Viewer Example
– TextView object has no scroll
bars and border by default
(not always needed)
– ScrollDecorator to add them
– BorderDecorator to add a thick
black border around the
The University of 30
Decorator Pattern – Text Viewer Example
– Compose the decorators with the TextView to produce both the border and the
scroll behaviours for the TextView
The University of 31
Decorator Pattern – Text Viewer Example
The University of 32
Decorator – Participants
– Component (VisualComponent)
– Defines the interface for objects that can have responsibilities added to them
dynamically
– ConcreteComponent (TextView)
– Defines an object to which additional responsibilities can be attached
– Decorator
– Maintains a reference to a Component object and defines an interface that
conforms to Component’s interface.
– ConcreteDecorator (BorderDecorator, ScrollDecorator)
– Adds responsibilities to the component
The University of 33
Decorator – Text Viewer Example
– VisualComponent is the abstract class for visual objects
– It defines their drawing and event handling interface
– Decorator is an abstract class for visual components that decorate the other
visual components
– It simply forwards draw requests to its component; Decorator subclasses can
extend this operation
– The ScrollDecorator and BorderDecorator classes are subclasses of
– Can add operations for specific functionality (e.g., ScrollTo)
The University of 34
– Collaborations
– Decorator forwards requests to its Component object. It may optionally
perform additional operations before and after forwarding the request.
– Applicability
– to add responsibilities to individual objects dynamically and transparently,
without affecting other objects
– For responsibilities that can be withdrawn
– When extension by sub-classing is impractical
• Sometimes a large number of independent extensions are possible and
would produce an explosion of subclasses to support every combination.
The University of 35
Consequences (1)
– More flexibility and less complexity than static inheritance
– Can add and remove responsibilities to objects at run-time
– Inheritance requires adding new class for each responsibility (increase
complexity)
– Avoids feature-laden (heavily loaded) classes high up in the hierarchy
– Defines a simple class and add functionality incrementally with Decorator
objects – applications do not need to have un-needed features
– You can define new kinds of Decorators independently from the classes of
objects they extend, even for unforeseen extensions
The University of 36
Consequences (2)
– Decorator and its component are not identical
– Decorated component is not identical to the component itself – you shouldn’t
rely on object identity when you use decorator
– Many little objects
– Can become hard to learn and debug when lots of little objects that look alike
– Still not difficult to customize by those who understand them
The University of 37
Façade Pattern
Object Structural
The University of 38
Structural Patterns (GoF)
Pattern Name Description
Adapter Allow classes of incompatible interfaces to work together. Convert the interface
of a class into another interface clients expect.
Decorator Attach additional responsibilities to an object dynamically (flexible alternative to
subclassing for extending functionality)
Façade Provides a unified interface to a set of interfaces in a subsystem. Defines a
higher-level interface that simplifies subsystem use.
The University of 39
Motivated Scenario
– Suppose you are going to seek some advices from your
UG/PG academic advisors. However, there are many
academics and you might know who takes care of your major.
The University of 40
Façade Motivation
A facade object provides a single, simplified interface to the more general
facilities of a subsystem
The University of 41
Façade Pattern
– Provide a unified interface to a set of interfaces in a subsystem. It
defines a higher-level interface that makes the subsystem easier to use
– Applicability
– You want to provide a simple interface to a complex subsystem
– There are many dependencies between clients and the implementation
classes of an abstraction
– You want to layer your subsystem. Façade would define an entry point
to each subsystem level
The University of 42
Façade – Structure
The University of 43
Façade – Participants
– Knows which subsystem classes are responsible for a request.
– Delegates client requests to appropriate subsystem objects.
– Subsystem classes
– Implement subsystem functionality.
– Handle work assigned by the Façade object
– Have no knowledge of the facade; they keep no references to it.
– Collaborations
– Clients communicate with the subsystem by sending requests to Façade, which forwards
them to the appropriate subsystem object(s).
• Although the subsystem objects perform the actual work, the façade may have to do
work of its own to translate its interface to subsystem interfaces
– Clients that use the facade don’t have to access its subsystem objects directly
The University of 44
– Collaborations
– Clients communicate with the subsystem by sending requests to Façade, which forwards
them to the appropriate subsystem object(s).
• Although the subsystem objects perform the actual work, the façade may have to do
work of its own to translate its interface to subsystem interfaces
– Clients that use the facade don’t have to access its subsystem objects directly
The University of 45
Façade Pattern – Example
class Façade {
subClass1 s1;
subClass2 s2;
public Façade() {
s1 = new subClass1();
s2 = new subClass2();
public void methodA() {
s1.method1();
s2.method2();
class subClass2 {
public void method2() {
// method body }
class subClass1 {
public void method1() {
// method body }
How about Client?
Façade façade = new Façade();
façade.methodA();
The University of 46
Consequences
– Simplify the usage of an existing subsystem by defining your own interface
– Shields clients from subsystem components, reduce the number of objects
that clients deal with and make the subsystem easier to use.
– Promote weak coupling between the subsystem and the clients
– Vary the components of the subsystem without affecting its clients
– Reduce compilation dependencies (esp. large systems) – when subsystem
classes change
– Does not prevent applications from using subsystem classes if they need to.
Choice between ease of use and flexibility.
The University of 56
Façade – A Brief Summary
– Name: Façade
– Problem: A common, unified interface to a disparate set of implementations or
interfaces is required. There may be undesirable coupling to many things in the
subsystem, or the implementation of the subsystem may change
– Solution: Define a single point of contact to the subsystem – a façade object that
wraps the subsystem. It represents a single unified interface and is responsible for
collaborating with the subsystem components.
The University of 57
Task for Week 12
– Submit weekly exercise on canvas before 23.59pm Saturday
– Well organize time for assignment 3
The University of 58
What are we going to learn on week 13?
– Unit Review
The University of 59
References
– . 2004. Applying UML and Patterns: An Introduction to Object-
Oriented Analysis and Design and Iterative Development (3rd Edition).
PTR, Upper Saddle River, NJ, USA.
– , , , and .
1995. Design Patterns: Elements of Reusable Object-Oriented Software.
Addison- Publishing Co., Inc., Boston, MA, USA.
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com