Software Construction & Design 1
The University of Sydney Page 1
Software Construction and
Design 2
SOFT3202 / COMP9202
Advanced Design Patterns
(GoF & Enterprise)
School of Information Technologies
Dr. Basem Suleiman
The University of Sydney Page 2
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 copyrightprotection under
the Act.
Do not remove this notice.
The University of Sydney Page 3
Agenda
– GoF Design Patterns
– Visitor
– Template Method
– Model-View-Controller
– Page Controller
– Template View
The University of Sydney Page 4
Visitor Design Pattern
(GoF)
Object Behavioural
The University of Sydney Page 5
Motivation – A Compiler
– A compiler represents programs as abstract
syntax trees
– Operations like type-checking, variable
assignment and code generation
– Different classes (nodes) for different statements
(e.g., assignment statement, arithmetic
expressions
– Discuss: is this a good design? Why/why not?
The University of Sydney Page 6
Motivation – A Compiler
– Problems:
– Operations are distributed across various
node classes
• Difficult to understand, maintain and
change design
– Add new operations will require
recompiling all of the classes
• Difficult to extend
The University of Sydney Page 7
A Compiler Application – Improved Design
– .
Node Hierarchy
Node Visitor Hierarchy
The University of Sydney Page 8
Visitor Pattern – Class Hierarchies
– Node Hierarchy
– For the elements being operated on
– Node Visitor Hierarchy
– For the visitors that define operations on the elements
– To create a new operation, add a new subclass to the visitor
hierarchy
The University of Sydney Page 9
Visitor Pattern – How it Works
– Group set of related operations from each class in a separate object
(visitor)
– Pass this object to elements of the syntax tree as it is traversed
– An element accepts the visitor to be able to send request to (element passed
as an argument)
– The visitor will run the operation for that element
The University of Sydney Page 10
Visitor Pattern
– Object behavioral
– Intent:
– Modify a new operation without changing the classes of the elements on which it
operates
– Applicability:
– You want to perform operations on objects that depend on their concrete classes
– You want to avoid mixing many distinct unrelated objects’ operations in an object
structure with their classes
– The classes that define the object structure rarely change, but often it is needed to
define new operations over the structure
The University of Sydney Page 11
Visitor Pattern – Structure
–
By Translated German file to English, CC BY 3.0, https://en.wikipedia.org/w/index.php?curid=52845911
The University of Sydney Page 12
Visitor Pattern – Participants
– Visitor (NodeNisitor)
– Declares a Visit operation for each class of ConcreteElement in the object structure
– Classes identified by the operation’s name and signature
– ConcreteVisitor (TypeCheckVistor)
– Implement each operation declared by Visitor
– Each operation implements a fragment of the algorithm defined for the
corresponding class of object in the structure
– Element (Node)
– Defines an “Accept” operation that takes a visitor as an argument
The University of Sydney Page 13
Visitor Pattern – Participants
– ConcereteElement (AssignmentNode,VariableRefNode)
– Implements Accept operation (visitor as argument)
– ObjectStructure (Program)
– Can enumerate its elements
– May either be composite or a collection
– May provide an interface to allow the visitor to visit its elements
The University of Sydney Page 14
Visitor Pattern – Collaboration
The University of Sydney Page 15
Visitor Pattern – Benefits
– Easy way to add new operations
– Add a new Visitor
– Gather related behaviors (algorithms defined in the Visitors)
– Specific data structure can be hidden in the visitor
– Visiting across class hierarchies
– It can visit object structures with different types of elements (unlike iterator)
– State accumulation in the object structure
– Otherwise, pass the state as an argument to the operations or declare it as global
variables
The University of Sydney Page 16
Visitor Pattern – Drawbacks
– Violating encapsulation
– It may enforce using public operations that access an element’s internal state
– Difficult to add new concrete element classes
– Adding new Concrete Element requires adding new abstract operation on Visitor
and a corresponding implementation in every Concrete Visitor
• Exception: default implementation to be provided or inherited by most Concrete Visitors
– Consider the likelihood to change the algorithm applied over an object structure or
classes of objects that make up the structure
The University of Sydney Page 17
Visitor Example – Element Implementation
The University of Sydney Page 18
Visitor Example – Visitor Implementation
The University of Sydney Page 19
Visitor Example – Client Implementation
– What is the output of this code?
The University of Sydney Page 20
Visitor – Implementation (1)
– Each object structure will be associated with a Visitor (abstract class)
– Declares VisitConcreteElement for each class of ConcreteElements defining the object
structure
– Visit operation declares a particular ConcreteElemnt as its argument to allow the
visitor to access the interface of ConcreteElement directly
– ConcreteVistor classes override each visit operation to implement visitor-specific
behavior
– ConcreteElement classes implement their Accept operation that calls the
matching Visit operation on the Visitor for that ConcreteElement
The University of Sydney Page 21
Visitor – Implementation (2)
– Double dispatch
– The execution of an operation depends on the kind of request and the types of two
receivers
– Visitor pattern allows adding operations to classes without changing them
through the Accept method which is double dispatch
– Accept method depends on Visitor and Element types which let visitors request
different operations on each class of element
The University of Sydney Page 22
Visitor – Implementation (3)
– Traversing the object structure; a visitor must visit each element of the object
structure – How?
– Can be a responsibility of
– Object structure: a collection iterates over its elements calling the Accept operation
on each (use Composite)
– Separate iteration object: using an Iterator to visit the elements
• Internal operator will call an operations on the visitor with an element as an
argument (not using double dispatching)
– Visitor:implement the traversal logic in the Visitor
• Allows to implement particularly complex traversal
• Code duplication
The University of Sydney Page 23
Visitor – Related Patterns
– Composite
– The composite pattern can be used to define an object structure over which
a Visitor can iterate to apply an operation
– Interpreter
– Visit or may be applied to do the interpretation
The University of Sydney Page 24
Template Method Pattern
(GoF)
Class behavioural
The University of Sydney Page 25
Motivating Scenario
– Application framework
– Application opens existing documents stored in external format
– Document represents the document’s info once its read
– Sub-classing:
– SpreadsheetDocument and
SpreadsheetApplication are
Spreadsheet Application
– OpenDocument() to define the
algorithm for opening and
reading a document (Template
Method)
The University of Sydney Page 26
Motivating Scenario – Template Method
– A template method defines abstract operations (algorithm) to be concretely
implemented by subclasses
– Application sub-classes
– Some steps of the algorithm (e.g., for CanOpenDocument() and DoCreateDocument())
– Document sub-classes
– Steps to carry on the operation (e.g., DoRead() to read the document)
– Let sub-classes know when something is about to happen in case they care
– E.g., AboutToOpenDocument()
The University of Sydney Page 27
Template Method Pattern
– Class behavioral
– Intent
– Let subclasses redefine certain steps of an algorithm without changing the algorithm’s structure
– Applicability
– Implement invariant parts of an algorithm once and let subclasses implement the varying
behavior
– Common behavior among subclasses to reduce code duplication (“refactoring to generalize”)
– Control subclasses extensions
• Template method calls hook operations at specific points
The University of Sydney Page 28
Template Method Pattern – Structure
– .
The University of Sydney Page 29
Template Method – Participants and Collaboration
– AbstractClass (Application)
– Defines abstract primitive operations
– Implement a template method defining an algorithm’s skeleton
– The template method calls primitive operations and AbstractClass’ operations
– ConcreteClass (MyApplication)
– Implements the primitive operations to perform sub-class specific steps of the
algorithm
– Relies on Abstract class to implement invariant algorithm’s steps
The University of Sydney Page 30
Template Method – Consequences
– Code reuse (e.g., class libraries)
– Inverted control structure (“the Hollywood principle” – “Don’t call us, we’ll call you”
– Template methods can call:
– Concrete operations (ConcreteClass or client classes)
– Concrete AbstractClass operations
– Primitive (abstract) operations (must be overridden)
– Factory methods
– Hook operations
• Provides default behavior that subclass can extend if needed
• Often does nothing by default, subclass override it to extend its behavior
– Subclasses must know which operations are designed for overriding (hook or
abstract/primitive)
The University of Sydney Page 31
Template Method Pattern – Implementation
– Minimize primitive operations a subclass must override
– More primitive operations can increase client’s tasks
– Naming conventions to identify operations that should be overridden
– E.g., MacApp framework (Macintosh applications) prefixes template method names
with “Do” (DoRead, DoCreateDocument)
The University of Sydney Page 32
Template Method Pattern – Related Patterns
– Factory
– Template Methods often call Factory Methods
– e.g., DoCreateDocument called by OpenDocument
– Strategy
– Strategy vary the entire algorithm using delegation
– Template method vary part of an algorithm using inheritance
The University of Sydney Page 33
Model View Controller
Enterprise (Web) Application
The University of Sydney Page 34
Model View Controller (MVC)
– “Splits user interface interaction into three distinct roles”
The University of Sydney Page 35
MVC – How it Works
– Model
– An object represent information about the domain
– E.g., customer object
– View
– Representation of the model (data) in the UI
– UI widget or HTML page rendered with info from the
model
– Controller
– Handle user interactions, manipulate the model and update
the view accordingly
The University of Sydney Page 36
MVC – When to Use it
– MVC separate the presentation from the model and the controller from the
view
– Benefits of separating the presentation from the model:
– Separation of concerns (UI design vs. business policies/database interactions)
– Multiple different views based on the same model
– Easier to test the domain logic without irrespective to UI
The University of Sydney Page 37
MVC – View and Model
– Dependencies
– The presentation depends on the model but not vice-versa
– Maintain the presentation without changing the model
– Discuss:
– What design consequences that might arise from the
dependency of the presentation on the model? How to
addressed it?
The University of Sydney Page 38
MVC – View and Model
– Dependencies
– The presentation depends on the model but not vice-versa
– Maintain the presentation without changing the model
– Discuss:
– What design consequences that might arise from the dependency of the
presentation on the model? How to addressed it?
– Several presentations of a model on multiple windows/UIs. If the user makes
changes to the model through one of the presentations, this should be
reflected in the other presentations
– Use the Observer pattern (GoF); presentation is observer of the model
The University of Sydney Page 39
MVC –View and Controller
– Separation/dependency is less important
– Can be designed/implemented differently
– One view and two controllers to support “editable” and “non-editable”
behavior
• Controllers as Strategies (GoF) for the view
– In practice, one controller per view
– Web interfaces help popularizing the separation
– Some GUI frameworks combine view and controller but led to confusion
The University of Sydney Page 40
MVC – Page Controller
“An object that handles a request for a specific page or action on a
Web site”
The University of Sydney Page 41
Page Controller – How It works
– One module on the Web server act as the controller for each page on the
Web site (ideally)
– With dynamic content different pages might be sent, controllers link to
each action (e.g., click a link or button)
– Page controller can be structured as a script (e.g., servlet) or as a server
page (e.g., PHP, JSP)
The University of Sydney Page 42
Page Controller – Responsibilities
– Decode the URL and extract form data for the required request action
– Create and invoke any model objects to process the data
– Decide which view to display the result page and forward model
information to it
– Invoke helper objects to help in handling a request
– Handlers that do similar tasks can be grouped in one (reduce code
duplication)
The University of Sydney Page 43
Page Controller – When to Use it
– Whether to use Page Controller or Front Controller?
– Page controller works particularly where most URLs can be handled with a
server page or script, and more complex ones with helper objects
The University of Sydney Page 44
Page Controller – Example
– Simple display with a servlet Controller and a JSP view in Java
– http://www.thingy.com/recordingApp/artist?name=danielaMercury
The University of Sydney Page 45
Page Controller – Example
– Mapping incoming requests (URLs) to corresponding controllers
The University of Sydney Page 46
Page Controller – Example
– Class controller for handling /artist requests
The University of Sydney Page 47
MVC – Template View
– “Renders information into HTML by embedding markers in an
HTML page”
The University of Sydney Page 48
Template View – Embedding the Markers
– HTML-like tags which will be treated differently (e.g., XML)
– Using special text markers not recognised by HTML editor but easier to
understand and maintain
– Server pages (ASP, JSP, EJS) allows to embed programming logic (known
as scriplets)
– Not easy to understand when it becomes complex (programming logic +
display)
– E.g., conditional display, iteration
The University of Sydney Page 49
Template View – Helper Objects
– Helper objects can be used to handle the programming logic where
possible
– This can simplify the views by having those markers to be replaced with
dynamic content
– E.g., conditions and iterations logic in the helper object and called from the
template view
– Developers can focus on the logic (helper objects) and designers on the
views (template view)
The University of Sydney Page 50
MVC – Web Application
Web
Browser
Application/Web Server
Controller Models
View
(Templates)
Routes
DB Server
Database
Read/write
data
HTTP responses
Forward requests to
appropriate controller
– Example of MVC design for Web application using Node.js/Express.js
The University of Sydney Page 51
MVC – Full Workflow (Example Node.js/Express.js)
Router Controller Model Database
Request
1. Request comes
into application
2. Request gets
routed to controller
3. Controller may send
request to model for data
4. Model may need to talk
to a data source (database)
to manipulate data
6. Model responds
to controller
5. Data source sends
result back to model
7. Controller pass
data to view
8. View generate
HTTP response and
sends back to client
• Data base related code should be put in model layer
• Controller should not have knowledge about the actual database
• Modularity allows easy switching between technologies
• e.g. different view templates, different database management systems
Response
View
The University of Sydney Page 52
References
– Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides.
1995. Design Patterns: Elements of Reusable Object-Oriented Software.
Pearson.
– Martin Fowler (With contributions from David Rice, Matthew Foemmel,
Edward Hieatt, Robert Mee, and Randy Stafford). 2003. Patterns of
Enterprise Applications Architecture. Pearson.
– Alexander Shevts, Dive into Design Patterns. ebook
– Web Application Development (COMP5347) slides
The University of Sydney Page 53
W9 Tutorial: Practical
Exercises/coding
W9 Lecture: Enterprise Design
Patterns
Design Pattern Assignment
Reviews
There are no reviews yet.