Programming 2 (PR2)

Lecture 12
Introduction to Design Patterns
 Outline
● What is design pattern?
● Class design patterns
● Singleton
● Factory method
● Derived attribute
● Recursive class

61FIT3PR2 2
 References
[1] Duc L. M. (2021), Object Oriented Program Develop-
ment, Chapter 9.
[2] Gamma, E., Helm, R., Johnson, R., Vlissides, J., and
Booch, G. (1994). Design Patterns: Elements of
Reusable Object-Oriented Software. Addison-Wes-
ley Professional, Reading, Mass, 1st edition

61FIT3PR2 3
 Definition:
architectural design pattern
● Design pattern has its root in buiding architectural
design:

“each pattern describes a problem which occurs

over and over again in our environment, and then
describes the core of the solution to that problem,
in such a way that you can use this solution a
million times over” (Alexander et al., 1977)

61FIT3PR2 4
 Definition: OOP design pattern
● Design pattern is a construct that “. . . names,
abstracts, and identifies the key aspects of a
common design structure that make it useful for
creating a reusable object-oriented design.”
(Gamma et al., 1994)

61FIT3PR2 5
 Pattern description format
● Description format provides a uniform and
structural means for documenting the patterns
● A high-level format defined by Gamma et al.
consists of 5 elements:
● name: is unique and encapsulates what the pattern
is about
● problem: aim and motivation
● solution: abstract design model
● example: application example of the pattern
● consequences: advantages and disadvantages

61FIT3PR2 6
 Four design patterns
● Four patterns that address common problems
concerning:
● object creation
● object structure
● Object creation:
● singleton
● factory method
● Object structure:
● derived attribute
● recursive class
61FIT3PR2 7
 Singleton
 Problem
 Solution
 Example
 Consequences
 Problem
● Intent: restrict a class to have one valid object
and provide a shared reference to this object
● Motivation: for some classes, only one instance
is necessary
● multiple instances leads to a waste of memory
● e.g. There can be many printers, but only one printer
spooler.
● e.g. There can be many windows but only one window
manager.
● e.g. There can be many DB queries but there should
only be one DB connection.

61FIT3PR2 9
 Solution
● How to design classes to have at most one object?
● create a class (static) variable named instance to
refer to the object
● create a private constructor to initialise the object
● How to make this object accessible to client
programs?
● create a public stand-alone procedure getInstance
● create the object once and assigns to instance
● return instance

61FIT3PR2 10
 Design diagram

● Singleton: the class that is designed as singleton

● ClientProg: represents client programs that use
the singleton class

61FIT3PR2 11
CODE
Example: CustomerMan

● A subsystem that manages Customer objects

● Singleton = CustomerMan

61FIT3PR2 12
 Consequences
● Advantages:
● simple enforcement of a single object without the
need to use a separate object management class
● conserves memory by preventing unnecessary
objects from being created
● extensible to support a predetermined number of
instances
● Disadvantages:
● life cycle dependency: object is not garbage
collected unless the class is unloaded

61FIT3PR2 13
 Factory method
 Problem
 Solution
 Example
 Consequences
 Problem
● Intent:
● define a method that creates objects of a class
● the actual type may not be known at compile time
● Motivation:
● actual type is the type of the object created at run-time
● actual type may depend on a run-time condition,
outside control of the client program
● client must not call the constructor directly
● needs to separate object creation logic from the client
program

61FIT3PR2 15
 Solution
● Q1: What abstraction should we use to
represent the object creation logic?
● create a factory method in a separate class

● Q2: How does this abstraction easily support

multiple object types?
● place multiple factory methods in a factory class

61FIT3PR2 16
 Design diagram

● FactoryClass: represents factory class

● createSomeCls1,2: stand-alone factory
methods, one for each class
● SomeClass1, SomeClass2: actual types of
objects (not known to ClientProg at compile-
time)
61FIT3PR2 17
Example

61FIT3PR2 18
CODE
Example

● createCustomer: factory method

61FIT3PR2 19
Example

61FIT3PR2 20
Example

61FIT3PR2 21
 Consequences
● Advantages:
● separation of concerns: modular design and
better code reuse
● centralised object creation rule enforcement:
useful when object creation logic is complex
(involving many dependent objects)
● Disadvantages:
● added layer of indirection: would affect run-time
performance

61FIT3PR2 22
 Derived attribute
 Problem
 Solution
 Example
 Consequences
 Problem
● Derived attribute = attribute whose value is
computed from other attributes of the same class
● Intent: define a derived attribute of a class
● Motivation:
● derived attribute provides information about some
observed parts of an object
● a getter operation can be used but needs to compute
the attribute value at every invocation
● more desirable solution is to compute the value once &
record it for subsequent uses (esp. when derived value
is frequently used or involves non-trivial computation)
61FIT3PR2 24
 Solution
● How to record the computed information and save it
for subsequent use?
● create an instance variable (called derived attribute)
● but do not create a mutator for it
● How to update the recorded information when the
observed parts are changed?
● create a helper operation to compute the value
● invoke helper operation when the observed parts are
changed (typically in constructor and mutator
operations)

61FIT3PR2 25
 Design diagram

● part: the observed part

● aDerived: derived attribute
● updateADerived: helper operation

61FIT3PR2 26
CODE
Example: Customer

lect10.derivedattrib.Customer

61FIT3PR2 27
 Consequences
● Advantages:
● enhanced encapsulation through making the
derived attribute a part of the object state.
● increased efficiency through minimising the
computation time of the derived attribute value
● Disadvantages:
● increased object state complexity by the
introduction of the derived attributes

61FIT3PR2 28
 Recursive class
 Problem
 Solution
 Example
 Consequences
 Recursive class

● Recursive class = class of objects that are defined

by a recursive definition
● Recursive definition inductively defines class(es)
of some objects in terms of the objects themselves:
● Consists of two clauses: basis and induction
● Basis: define the simple (‘smallest’) objects
● Induction: define larger objects in terms of smaller ones

61FIT3PR2 30
 Recursive definition usage
● RD is one of the key constructs used in computer
science and software engineering
● Used to define sets, whose elements have some
structural relationship
● Well-known examples include data types, strings
and grammar rules

61FIT3PR2 31
 Example: Factorial definition

BASIS.
1! = 1.
INDUCTION.
n! = n × (n − 1)!.

61FIT3PR2 32
 Problem
● Intent:
● design a class whose objects are constructed through
a recursive definition
● Motivation:
● recursion is an important construct in CS, SE
● a common solution is recursive function, but this only
gives the final result, forgetting the state structure
consisting of all the intermediate objects
● a better solution is called for that captures the objects
and the state structure that defines them

61FIT3PR2 33
 Solution
● How to capture the recursive definition?
● define a recursive class that captures the definition
● header’s @object section: captures the definition
● define private constructor operation(s) to realize the
basis and induction clauses
● How to capture the state structure?
● create attribute(s) that capture object value and state
structure

61FIT3PR2 34
 Solution (cont.)
● How to efficiently execute the RD to create objects
(reusing the state structure where possible)?
● create static getter operation: computes and returns
an object.
– looks up in state structure for pre-computed objects
– only invokes the constructor if the object is not yet created
● private look-up operation: a helper operation
– looks up in the state structure for an object given its index
● Thus, each object is computed only once and is
served through the state structure
● could be more efficient than recursive function if objects
are used many times
61FIT3PR2 35
 Design diagram

● RecursiveClass<T>: enhances reuse through T

● attribute value: object value (immutable)
● static attribute stateStruc: the state structure (immutable)
● constructor: takes an object index as parameter
● getValue: observer for attribute value
61FIT3PR2 36
CODE
Example

● RecursiveClass = Fact

61FIT3PR2 37
 Design alternatives
● For more complex RDs (e.g. string composition)
that takes as input smaller objects
● Object index is not enough to generate a new object
● Solution needs to be improved as follows:
● static getter operation: change parameters to take
smaller objects as input
● constructor(s): change parameters to match

61FIT3PR2 38
 Consequences
● Advantages:
● explicitly captures the state structure of RD: a key
component
● improved performance in computing the objects:
every object is computed only once and served through
state structure
● Disadvantages:
● would requires more memory space to hold the state
structure

61FIT3PR2 39