The University of 1
Software Design and
Copyright By PowCoder代写 加微信 powcoder
Construction 1
SOFT2201 / COMP9201
Introduction to Design
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 4
– Design Patterns
– GoF Design Patterns
– Creational Deign Patterns
– Factory Method Pattern
– Builder Pattern
The University of 5
What is Design Pattern?
The University of 6
Design Patterns
– A pattern is a description of a problem and its solution
– Tried and tested ideas for recurring design problem
– Not readily coded solution, but rather the solution path to a
common programming problem
– Design or implementation structure that achieves a particular
The University of 7
Essential Components of a Pattern
– The pattern name
– e.g., Factory Method
– The problem
– The pattern is designed to solve (i.e., when to apply the pattern)
– The solution
– The components of the design and how they related to each other
– Consequence
– The results and trade-offs of applying the pattern
– Advantages and disadvantages of using the pattern
The University of 8
Gang of Four Patterns (GoF)
• Official design pattern reference
• Famous and influential book about design patterns
• Recommended for students who wish to become
• We will cover the most widely – used patterns
from the book
• 23 patterns in total – our unit will focus on 11
• GoF Design Patterns à Design Patterns as short
The University of 9
Design Patterns – Classification based on purpose
Scope Creational Structural Behavioural
Class Factory Method Adapter (class) Interpreter
Template Method
Object Abstract Factory
Chain of Responsibility
The University of 10
Design Patterns – Classification based on purpose
– Creational patterns
– Abstract the instantiation process
– Make a system independent of how its objects are created, composed
and represented
– Structural patterns
– How classes and objects are composed to form larger structures
– Behavioral patterns
– Concerns with algorithms and the assignment of responsibilities between
The University of 11
Design Patterns – Classification based on relationships
– Patterns often used together
– E.g., Composite often used with Iterator or Visitor
– Alternative Patterns
– E.g., Prototype often alternative to Abstract Factory
– Patterns results in similar designs
– E.g., Structure diagram of composite and Decorator are similar
The University of 12
Design Patterns – Classification based on relationships
Reponsibility
Interpreter
State Strategy
SingletonFlyweight
Structural
Behavioural
Creational
hysteresis
saving state
of iteration
composites
responsibilities
to objects
traversals
operations
strategies
dependency
management
changing skin
vs internals defining
algorithm’s
steps often
configure factory
dynamically
operations defining
* Adapted from the GoF book: Design Patterns
The University of 13
Selecting an Appropriate Design Pattern
It is useful to have some guidelines of how to select one. Here are
some thoughts on how you might do that:
– Consider the ways in which the design patterns solve problems.
– We will go into details on this for several design patterns
– Decide on what the intent of each design is.
– Without knowing what the motivation of the design pattern is, it will be
hard to know whether it is right for you
– Look at the relationships among patterns
– It makes sense to use patterns that have a clear relationship, rather than
one that you have manufacture ad hoc
The University of 14
Selecting an Appropriate Design Pattern
– Consider patterns with similar purpose
– Creational, Structural and Behavioral are quite different purposes so
you should consider which one you need
– Look at why redesign might be necessary
– Knowing why a redesign might be needed will help you select the right
design to avoid having to redesign later
– Why can vary?
– Your design should be open to variation where necessary
– Choose a design that will not lock you into a particular one, and enable
you to make variations without changing your design
The University of 15
Design Aspects Can be Varied by Design Patterns
Purpose Pattern Aspects that can change
Creational
Abstract Factory
Factory Method
families of product objects
how a composite object gets created
subclass of object that is instantiated
class of object that is instantiated
the sole instance of a class
Structural
interface to an object
implementation of an object
structure and composition of an object
responsibilities of an object without subclassing
interface to a subsystem
storage costs of objects
how an object is accessed; its location
The University of 16
Design Aspects Can be Varied by Design Patterns
Purpose Pattern Aspects that can change
Behavioral
Chain of Responsibility
Interpreter
Template Method
object that can fulfill a request
when and how a request is fulfilled
grammar and interpretation of a language
how an aggregate’s elements are accessed, traversed
how and which objects interact with each other
what private info. is stored outside an object, & when
number of objects that depend on another object; how the
dependent objects stay up to date
states of an object
an algorithm
steps of an algorithm
operations that can be applied to object(s) without changing
their class(es)
The University of 17
Creational Patterns
The University of 18
Creational Patterns
– Abstract the instantiation process
– Make a system independent of how its objects are created, composed and
represented
– Class creational pattern uses inheritance to vary the class that’s instantiated
– Object creational pattern delegates instantiation to another object
– Provides flexibility in what gets created, who creates it, how it gets created
The University of 19
Creational Patterns
Pattern Name Description
Abstract Factory Provide an interface for creating families of related or dependent objects
without specifying their concrete classes
a class only has one instance, and provide global point of access to it
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
The University of 20
Factory Method
Class Creational Pattern
An interface for creating an object
The University of 21
Motivated Scenario
– Suppose you have a general shape creator that can create a
variety of different shapes.
The University of 22
Motivated Scenario
Client Perspective:
The University of 23
Factory Method Pattern
– Purpose/Intent
– Define an interface for creating an object
– Let subclasses decide which class to instantiate.
– Let a class defer instantiation to subclasses
– Also known as
– Virtual Constructor
The University of 24
Factory Method Structure
Defines the interface of objects the
factory method creates
Implements the Product interface
Declares the factory method, which
returns an object of type Product.
Overrides the factory method to return
an instance of the ConcreteProduct
The University of 25
Factory Method Participants
– Defines the interface of objects the factory method creates
– ConcreteProduct
– Implements the Product interface
– Declares the factory method, which returns an object of type Product.
– ConcreteCreator
– Overrides the factory method to return an instance of the ConcreteProduct
The University of 26
Revisit the Motivated Example
The University of 27
Revisit the Motivated Example
Client Perspective
The University of 28
Factory Method Pattern
– Applicability
– A class cannot anticipate the class objects it must create
– A class wants its subclasses to specify the objects it creates
– Classes delegate responsibility to one of several helper subclasses, and you
want to localize the knowledge of which helper subclass is the delegate
– Benefits
– Flexibility: subclasses get a hook for providing an extension to an
object; connects parallel class hierarchies
– Limitations
– Can require subclassing just to get an implementation
The University of 29
Two varieties of Factory
– Variety 1: the Creator class is abstract
– This requires subclasses to be made because there is no reasonable
default value.
– On plus side, this avoids the problem of dealing with instantiating
unforeseeable classes
– Variety 2: the Creator class is concrete
– Creator may also define a default implementation of the factory
method that returns a default ConcreteProduct object
– This provides reasonable default behaviors, and enables subclasses to
override the default behaviors where required
The University of 30
Factory Registry — Selecting a Factory Method Source
– In essence, a mapping from identifier to implementation
– Responsibility for choice of Factory Method concentrated in one
public class FactoryRegistry {
private Map
public void registerFactory(Factory factory, Identifier identifier) {…}
public Factory getFactory(Identifier identifier) {…}
The University of 31
Object Creational Pattern
The University of 32
Motivated Scenario
– Suppose the design team is going outside to have a coffee
– John would like a CoffeeA that contains no milk and no sugar
– Xi would like a CoffeeB that contains no milk but full sugar
– Sue would like a CoffeeC that contains full milk and full sugar
The University of 33
– Purpose/Intent
– Separate the construction of a complex object from its representation so
that the same construction process can create different representations
– You have a range of implementations that might expand, so must be
flexible, or you want to create instances of complex objects
The University of 34
Builder — Structure
The University of 35
Builder – Participants
– Specifies an abstract interface for creating parts of a Product object
– ConcreteBuilder
– Constructs and assembles parts of the product by implementing the
Builder interface
– defines and keeps track of the representation it creates.
– provides an interface (GetResult) for retrieving the product
The University of 36
Builder – Participants
– Director
– Constructs an object using the Builder interface
– Represents the complex object under construction.
– ConcreteBuilder builds the product’s internal representation and defines the process
by which it’s assembled
– Includes classes that define the constituent parts, including interfaces for assembling
the parts into the final result
The University of 37
Revisit the Motivated Example
“abstract” builder one concrete builder as an example
The University of 38
Revisit the Motivated Example
director client perspective
The University of 39
– Applicability
– The algorithm for creating a complex object should be independent of
the parts that make up the object and how they’re assembled
– The construction process must allow different representations for the
object that’s constructed
– Benefits
– Gives flexibility that can be extended by implementing new subclasses
of the Builder, and isolates code of construction from implementation
– Limitations
– Not completely generic, less useful in situations where variety of
implementations is not high
The University of 43
Builder – Collaboration
Director d = new Director( );
Builder b = new ConcreteBuilder1( );
d.construct(b);
Product p = b.GetResult( );
The University of 44
Builder – Consequences (1)
– Varying product’s internal representation
– Because the product is constructed through an abstract interface, all you have to
do to change the product’s internal representation is define a new kind of
– Isolation of code construction and representation
– Each ConcreteBuilder contains all the code to create and assemble a particular
kind of product.
– Different Directors can reuse it to build Product variants from the same set of
The University of 45
Builder – Consequences (2)
– Finer control over the construction process
– The builder pattern constructs the product step by step under the director’s
– Only when the product finished does the director retrieve it from the builder
– The builder interface reflects the process of constructing the product more than
other creational patterns
The University of 46
Task for Week 5
– Submit weekly exercise on canvas before 23.59pm Saturday
– Prepare questions and ask during tutorial this week
The University of 47
What are we going to learn next week?
– Behavioral Design Patterns
– Strategy Pattern
– State Pattern
The University of 48
References
– , , , and .
1995. Design Patterns: Elements of Reusable Object-Oriented Software.
Addison- Publishing Co., Inc., Boston, MA, USA.
– . 2004. Applying UML and Patterns: An Introduction to Object-
Oriented Analysis and Design and Iterative Development (3rd Edition).
PTR, Upper Saddle River, NJ, USA.
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com