CS代写 SOFT2201/COMP9201:

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