程序代写代做代考 data structure Java database gui compiler algorithm interpreter Software Construction & Design 1

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 copyright protection 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