程序代写代做代考 gui flex SOFT2201/COMP9201: Software Design and Construction 1 Singleton, Decorator, and Façade

SOFT2201/COMP9201: Software Design and Construction 1 Singleton, Decorator, and Façade
Dr Xi Wu
School of Computer Science
The University of Sydney
Page 1

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 2

Agenda
– Creational Design Pattern – Singleton
– Structural Design Pattern
– Decorator and Façade
The University of Sydney
Page 3

Singleton Pattern
Object Creational
The University of Sydney Page 4

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
Singleton
Ensure a class only has one instance, and provide global point of access to it
The University of Sydney Page 5

Singleton
– Intent
– 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)
– There can be many printers in a system, but there should be only one printer queue
The University of Sydney Page 6

Singleton
– 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
– Structure
The University of Sydney
Page 7

Singleton
– 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
– Collaboration
– Clients access a Singleton instance solely through Singleton’s
instance() operation.
The University of Sydney
Page 8

Singleton Implementation
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 Sydney
Page 9

Decorator Pattern
Object Structural
The University of Sydney Page 13

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 Sydney Page 14

Decorator Pattern
– Intent
– Attach additional responsibilities to an object dynamically. Decorators
provide a flexible alternative to sub-classing for extending functionality
– 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
• Sometimesalargenumberofindependentextensionsarepossible and would produce an explosion of subclasses to support every combination.
The University of Sydney
Page 15

Decorator – Structure
The University of Sydney Page 16

Decorator – Structure
The University of Sydney Page 17

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 Sydney
Page 21

Decorator Pattern – Why Not Inheritance?
– Adding responsibilities using inheritance restricts runtime change, and requires an implementation for every decoration.
– This design is inflexible
• •
The University of Sydney
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
Page 22

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 TextView
The University of Sydney
Page 23

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 Sydney Page 24

Decorator Pattern – Text Viewer Example
The University of Sydney Page 25

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 Decorator
– Can add operations for specific functionality (e.g., ScrollTo)
The University of Sydney Page 26

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 Sydney Page 27

Decorator – Collaborations
– Collaborations
– Decorator forwards requests to its Component object. It may optionally perform additional operations before and after forwarding the request.
The University of Sydney
Page 28

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 Sydney
Page 29

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 Sydney
Page 30

Façade Pattern
Object Structural
The University of Sydney Page 31

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 Sydney Page 32

Façade Pattern
– Intent
– 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 Sydney Page 33

Façade Motivation
A facade object provides a single, simplified interface to the more general facilities of a subsystem
The University of Sydney Page 34

Façade – Structure
The University of Sydney Page 35

Façade Pattern – Example
class subClass1 {
public void method1() {
// method body }
}
class subSystem2 {
public void method2() {
// method body }
}
How about Client?
Façade façade = new Façade(); façade.methodA();
The University of Sydney
class Façade { subClass1 s1;
subClass2 s2; public Façade() {
s1 = new subClass1();
s2 = new subClass2(); }
public void methodA() { s1.method1(); s2.method2();
} }
Page 36

Façade – Participants
– Facade
– 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 Sydney Page 37

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 Sydney Page 38

Façade Pattern
– Façades can simplify using a series of complicated method calls and interactions
– Façades can wrap a complex set of packages with a simpler interface
– Easier to use
– Easier to maintain
– Promote weak coupling with the complex system
– Doesn’t prevent using the complex system directly if needed
The University of Sydney
Page 42

Task for Week 11
– Submit weekly exercise on canvas before 23.59pm Sunday
– Well organize time for assignment 3
– Attend Helpdesk session if you have any questions/difficulties on implementation perspective
The University of Sydney Page 49

What are we going to learn on week 12?
– Unit Review
The University of Sydney Page 50

References
– Craig Larman. 2004. Applying UML and Patterns: An Introduction to Object- Oriented Analysis and Design and Iterative Development (3rd Edition). Prentice Hall PTR, Upper Saddle River, NJ, USA.
– Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides.
1995. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA.
The University of Sydney
Page 51