SOEN 343 Software Design

1. SOEN 343Software Design Section H Fall 2006 Dr Greg Butler http://www.cs.concordia.ca/~gregb/home/soen343h-f06.html

2. 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

3. Recall the Greeting EA • A single servlet which offers the greeting “Hello”. • We refactored it, offering two alternative designs.

4. Review Question • On a blank sheet of paper … • Provide three class diagrams corresponding to the three design solutions of the Greeting EA.

5. Evaluating a Design • Which is a better design? • What is a good design?

6. 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.

7. Greeting EA Evolution … What if … • Support a personalized greeting. • Change “look” of output (e.g. bold the name). • Get full name from db.

8. Comparing Design Solutions

9. 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).

10. 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).

11. Controller Patterns Page Controller Template View Presentation Front Controller Transform View Domain Model Transaction Script Domain Data Mapper Table Module Active Record Data Mapper Row Data Gateway Table Data Gateway Data Source Table Data Gateway

12. Page Controller (done)

13. Front Controller Fowler: 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.

14. Front Controller GoF design pattern: Command Use a Command object to encapsulate the steps that are executed by a command. Command::doIt() executes command Allows Command::unDoIt() etc GoF design pattern: Decorator Decorator::m() adds additional behaviour, but delegates to real Object::m() for real behaviour Eg, logging command execution before/after executing command

15. 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&…

16. Front Controller

17. Front Controller

18. Front Controller (Fowler)Command (GoF) Patterns FrontCommand + init ( ) + processRequest ( ) RemoveStudentCommand ViewStudInfoCommand + processRequest ( ) + processRequest ( )

19. Front Controller: Sequence Diagram

20. Front Controller: ProcessRequest

21. Front Controller (cont’d)

22. Front Controller: Advantages?

23. Web EA Redesign Exercise • Refactoring a DoItAll Servlet, let me count the ways …

24. Do-it-all Servlet or Script Do-it-allServlet or Script Presentation Domain Data Source

25. Do-it-all Servlet or Script, Class publicclass DoItAll extends javax.servlet.http.HttpServlet { protectedvoid doGet( HttpServletRequest request, HttpServletResponse response) throws ... // { … } }

26. 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.

27. 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>");

28. 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.

29. redesign Redesigning Do-it-all (2 classes) [#1] Do-it-all Presentation Domain Data Source Note:

30. redesign Redesigning Do-it-all (3 classes) [#3] Do-it-all Presentation Domain Data Source

31. redesign Redesigning Do-it-all (4 classes) [#4] Do-it-all Presentation Domain Data Source

32. redesign Redesigning Do-it-all : Adding … (5 classes) [#5] Do-it-all Presentation Domain Data Source

33. redesign Redesigning Do-it-all : Adding … [#5b] Do-it-all Presentation Domain Data Source

34. redesign Redesigning Do-it-all (5 classes) [#5c] Do-it-all Presentation Domain • Is there anything wrong with this design? (Hint: consider the dependencies and the layering style.) Data Source

35. redesign Redesigning Do-it-all (6 classes) [#6] Do-it-all Presentation Domain Data Source

36. Pure Fabrication Problem: Existing objects, ie domain objects, are not appropriate to have the responsibility Solution suggested by Information Expert not appropriate Might violate high cohesion, low coupling Solution: Fabricate (ie create, make up) a new object to hold the responsibility

37. 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?

38. GRASP: Pure Fabrication Design of objects • Representational decomposition • Behavorial decomposition It’s OK for OO software to have objects representing behaviour, ie use case, process, function, strategy, TS But do not overdo it All GoF design patterns are Pure Fabrications

39. Indirection Problem: 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 pattern Intermediatory to external tax calculators

40. Fig. 25.10

41. Indirection “Most problems in computer science can be solved by another level of indirection”