SOEN 343Software Design

Section H Fall 2006Dr Greg Butler

http://www.cs.concordia.ca/~gregb/home/soen343h-f06.html

Outline• Week 9 lectures: Evaluate Good Design

• Page Controller and Front Controller– Note Command Pattern

• Web EA Do-It-All TS Re-design

• GRASP Principles– Pure Fabrication– Indirection

Recall the Greeting EA

• A single servlet which offers the greeting “Hello”.

• We refactored it, offering two alternative designs.

#doGet(in req, in resp)

GreetingServlet

Review Question

• On a blank sheet of paper …• Provide three class diagrams

corresponding to the three design solutions of the Greeting EA.

Evaluating a Design

• Which is a better design?• What is a good design?

What is a good design?

• Satisfies user needs, requirements.• Reveals intent.• Is a simple as possible.• Minimizes cost of … likely changes.And …• High cohesion.• Low coupling.

Greeting EA Evolution … What if …

• Support a personalized greeting.• Change “look” of output (e.g. bold the

name).• Get full name from db.

Comparing Design Solutions

Property Sol’n 1 Sol’n 2 Sol’n 3

Correct

Intent clear

SimplestAcc.

ChangeCohesion

Coupling

GRASP: Controller

• Who handles a system event?– E.g. “List Movies”

• Main choices: assign to a design entity representing– Overall system,

or subsystem (façade controller).– A Use Case scenario

(often named, e.g. ListMovieHandler).

GRASP: Controller

• Who handles a system event?– E.g. “List Movies”

• Main choices: assign to a design entity representing– Overall system,

or subsystem (façade controller).– A Use Case scenario

(often named, e.g. ListMovieHandler).

Dom

ain

Data

Sou

rce

Table Data Gateway

Transaction Script Domain Model

Data Mapper

Row Data Gateway

Front Controller

Template View

Transform View

Page Controller

Pres

enta

tion

Active Record

Controller Patterns

Table Module

Data Mapper

Table Data Gateway

Page Controller (done)

Front ControllerFowler: A controller that handles all requests

for a web site.

The Front Controller consolidates all request handling by channeling requests through a single handler object. This object can carry out common behaviour which can be modified at runtime with decorators. This handler then dispatches to command objects for behaviour particular to a request.

Front ControllerGoF design pattern: Command

Use a Command object to encapsulate the steps that are executed by a command.

Command::doIt() executes commandAllows Command::unDoIt() etc

GoF design pattern: DecoratorDecorator::m() adds additional behaviour, but delegates

to real Object::m() for real behaviourEg, logging command execution before/after executing

command

Page vs Front Controller – Differences in URL Page Controllers for A1 • http:/stu.cs/343A1/ViewTaskList• http:/stu.cs/343A1/AddTask• http:/stu.cs/343A1/RemoveAllTasks• …

Front Controller for A1• Base URL: http:/stu.cs/343A1/frontController• …/frontController

?command=ViewTaskList• …/frontController

?command=AddTaskGrade&title=abc&…

Front Controller

FrontServlet

# processRequest ( )- getCommand ( )- getCommandClass ( )

FrontCommand

+ init ( )+ processRequest ( )

AddStudent

+ processRequest ( )

Servlet

+ init ( )+ destroy ( )# processRequest ( )# doGet ( )# doPost ( )+ getServletInfo ( )+ forward ( )+ forwardAbsolute ( )+ getUrlBase ( )

# controller

0..1

Error

+ processRequest ( )

Front Controller

Front Controller (Fowler)Command (GoF) Patterns

FrontCommand

+ init ( )+ processRequest ( )

ViewStudInfoCommand

+ processRequest ( )

RemoveStudentCommand

+ processRequest ( )

FrontControllerServlet

# processRequest ( )- getCommand ( )- getCommandClass ( )+ getUrlBase ( )

Front Controller: Sequence Diagram

Front Controller: ProcessRequest

Front Controller (cont’d)

Front Controller: Advantages?

Web EA Redesign Exercise

• Refactoring a DoItAll Servlet, let me count the ways …

Dom

ain

Data

Sou

rce

Do-it-allServlet or Script

Pres

enta

tion Do-it-all Servlet or Script

Do-it-all Servlet or Script, Classpublic class DoItAll extends

javax.servlet.http.HttpServlet{

protected void doGet(HttpServletRequest request,HttpServletResponse response)throws ... //{…}

}

Redesigning This Application

• Redesign DoItAll so as to increase the class cohesion.

• Create new classes. Which EA patterns would you use?

• Distribute the doGet() method code (given on the next slide) into the new classes. Identify which lines would go into which classes.

Do-it-all Transaction Script, doGet()

String lastName = request.getParameter(“…"); Connection dbc = DbRegistry.getDbConnection();String findSql = "SELECT * from … where LastName = ?”;PreparedStatement dbQuery = dbc.prepareStatement(findSql);

dbQuery.setString(1, lastName);ResultSet rs = dbQuery.executeQuery();rs.next();String firstName = rs.getString("FirstName");lastName = lastName.toUpperCase();PrintWriter out = response.getWriter();response.setContentType("text/html");out.println("<h1>Hello "+firstName+" "+lastName+"</h1>");

Do-it-all Servlet Redesign: Separating Concerns

• The next few slides show ways in which we can separate concerns; i.e. distribute the functionality of the do-it-all script into separate classes.

• Combinations other than the ones shown are possible.

Dom

ain

Data

Sou

rce

Do-it-all

Pres

enta

tion Redesigning Do-it-all (2 classes) [#1]

redesignNote:

Dom

ain

Data

Sou

rce

Do-it-all

Pres

enta

tion Redesigning Do-it-all (3 classes) [#3]

redesign

Dom

ain

Data

Sou

rce

Do-it-all

Pres

enta

tion Redesigning Do-it-all (4 classes) [#4]

redesign

Dom

ain

Data

Sou

rce

Do-it-all

Pres

enta

tion

Redesigning Do-it-all : Adding … (5 classes) [#5]

redesign

Dom

ain

Data

Sou

rce

Do-it-all

Pres

enta

tion Redesigning Do-it-all : Adding … [#5b]

redesign

Dom

ain

Data

Sou

rce

Do-it-all

Pres

enta

tion Redesigning Do-it-all (5 classes) [#5c]

redesign

• Is there anything wrong with this design? (Hint: consider the dependencies and the layering style.)

Dom

ain

Data

Sou

rce

Do-it-all

Pres

enta

tion Redesigning Do-it-all (6 classes) [#6]

redesign

Pure FabricationProblem: Existing objects, ie domain

objects, are not appropriate to have the responsibilitySolution suggested by Information Expert not

appropriateMight violate high cohesion, low coupling

Solution: Fabricate (ie create, make up) a new object to hold the responsibility

GRASP: Pure Fabrication

• Assign a highly cohesive set of responsibilities to an artificial or convenience class that does not represent a problem domain concept—something made up, to support high cohesion, low coupling, and reuse.

• Can you think of an example from EA?

GRASP: Pure FabricationDesign of objects

– Representational decomposition– Behavorial decomposition

It’s OK for OO software to have objects representing behaviour, ie use case, process, function, strategy, TSBut do not overdo it

All GoF design patterns are Pure Fabrications

IndirectionProblem: How to assign responsibility to

avoid direct coupling? How to de-couple objects?

Solution: Assign responsibility to an intermediatory object to mediate between the two components

Example: Adapter patternIntermediatory to external tax calculators

Fig. 25.10

: Sale :TaxMasterAdapter

taxes = getTaxes( s )

t = getTotal

the adapter acts as a level of indirection to external systems

TCP socket communication

xxx...

«actor»:TaxMasterSystem. . .

Indirection“Most problems in computer science can be

solved by another level of indirection”