SOEN 343 Software Design

1
SOEN 343Software Design

• Section H Fall 2006
• Dr Greg Butler
• http//www.cs.concordia.ca/gregb/home/soen343h-f0
  6.html

2
Outline

• GRASP Principles
• Pure Fabrication
• Indirection
• Dice Game
• GoF Design Patterns
• Factory, Singleton, Adapter, Composite.

3
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

4
GRASP Pure Fabrication

• Assign a highly cohesive set of responsibilities
  to an artificial or convenience class that does
  not represent a problem domain conceptsomething
  made up, to support high cohesion, low coupling,
  and reuse.
• Can you think of an example from EA?

5
GRASP Pure Fabrication

• Design of objects
• Representational decomposition
• Behavorial decomposition
• Its 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

6
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

7
Fig. 25.10
8
Indirection

• Most problems in computer science can be solved
  by another level of indirection

9
Patterns and Principles

• We have (and still are) studying
• Larmans GRASP
• GoF
• Fowlers EA
• The most fundamental are the principles.

10
GRASP Interrelationships
11
Patterns apply principles, e.g.
12
Gang Of Four

• Gamma, Helm, Johnson, Vlissides
• Some patterns in Larman, Chap. 23,
• All patterns in XDE
• As documentation.
• As dynamic templates.

13
Overview of Patterns
14
GoF Pattern Summary Relationships
15
GoF Pattern Classification

• Behavioral Patterns
• Creational Patterns
• Structural Patterns

16
GoF Behavioral Patterns

• Chain of Responsibility
• Command
• Interpreter
• Iterator
• Mediator
• Memento

• Observer
• State
• Strategy
• Template Method
• Visitor

17
GoF Creational Patterns

• Abstract Factory
• Builder
• Factory Method
• Prototype
• Singleton

18
Command Pattern(Week 1 and Front Controller)

• Problem How to allow the same command to be
  invoked by
• Menu selection
• Alt-ctrl shortcut
• Commandline text entry, etc
• How to allow (unlimited) undo/redo
• How to keep a log/audit/history of commands
  invoked
• How to allow macro commands to be defined

19
Command Pattern (Week 1 and Front Controller)

• You have commands that need to be
• executed,
• undone, or
• queued
• Command design pattern separates
• Receiver from Invoker from Commands
• All commands derive from Command and implement
  do(), undo(), and redo()
• Also allows recording history, replay

20
Design Issue Ensure No More Than One Instance of
a Class is Created

• Given a class C, how can we ensure that only one
  instance of C is ever created?

21
Converting C to a Singleton.
22
Singleton Pattern

• Notice
• Constructor is no longer public.
• To access the instance use getUniqueInstance().
• All other attribute and method declarations of C
  stay the same.

23
Singleton C.getUniqueInstance()

• public static C getUniqueInstance()
• if(uniqueInstance null)
• uniqueInstance new C()
• return uniqueInstance

24
Thread-safe Creation Method

• public static synchronized C getUn()

25
Singleton Design Alternatives/Issues

• Create a class with static attributes and
  methods.
• Trade-offs consider how easy the following are
• Adapting the design so that x instances can be
  created (where x gt 1).
• Subclassing.
• Passing the instance as a parameter.
• (See Larman05, Section 26.5)

26
Singleton Design Issues (Contd)

• See Larman05, Section 26.5 for discussion of
• Design trade-offs, including
• eager/lazy evaluation of Singleton.uniqueInstance
  see.

27
Singleton UML
28
Singleton UML
29
Dice Game

• Simple game
• Player rolls a dice
• Score is the face value of the dice

30
Client Cannot Tell
31
Dice Game Refactoring

• We can apply
• Indirection principle.
• Decouple DiceGame from Dice by inserting an
  IDice interface in between.
• Introduce a Simple Factory class, DiceFactory.
• Make DiceFactory a Singleton.

32
Dice Game New Functionality

• Although we have ConstDice we still have a
• Problem
• Our DiceFactory only creates one type of IDice.
• Solutions
• Somehow we want the behavior of createDice() to
  vary.

33
DiceFactory.createDice().

• Possible solutions
• DiceFactory can read a System property to
  determine the class to instantiate (Larman05,
  p.441).
• Add a method to factory
• Generalize our solution further Abstract
  Factory.
• Any of these solutions will finally allow us to
  create our test class, e.g.

34
DiceGameTest JUnit TestCase

• public void testWinning()
• int faceValue 3
• DiceFactory.theOne().
• DiceGame game new DiceGame()
• game.roll()
• assertEquals("face value", faceValue,
  game.getFaceValue())
• assertTrue("won", game.won())

35
Factory

• Context / problemWho should be responsible for
  creating objects when there are special
  considerations, such as complex creation logic, a
  desire to separate the creation responsibilities
  for better cohesion, and so forth?
• SolutionCreate a Pure Fabrication object called
  a Factory.

36
Factory Example
37
Larmans comment on prev. figure

• Note that the factory methods return objects
  types to an interfacre rather than a class so
  that the factory can return any implementation of
  the interface.
• Factory methods can also

38
(Abstract) Factory Example (GoF)
39
Factory (in EAs)
FrontControllerServlet
FrontCommand
processRequest ( )
init ( )
- getCommand ( ) FrontCommand
processRequest ( )
- getCommandClass ( )
ViewStudInfoCommand
RemoveStudentCommand
processRequest ( )
processRequest ( )
40
New Version of Dice Game

• Support using a pair of Dice.
• How can this be added?

41
Multi-Dice Design
42
Composite (Larman05, 26.8)

• Context/problem
• How do you treat a group or composite structure
  of objects the same way (polymorphically) as a
  non-composite (atomic) object?
• Solution
• Define classes for composite and atomic objects
  so that they implement the same interface.

43
Dice Composite
44
Client Cannot Tell
45
Composite Ex. Objects
46
Composite Ex. Class Diagram
47
Must add be implemented by Line?

• In C add declared virtual subclass need not
  implement it.
• In Java if add is abstract, then subclasses must
  implement it.
• String add(Graphic g)
• throw new UnsupportedOperationException()
• Can you think of a better solution?

48
Composite Clients point-of-view
49
Composite Pricing Strategies

• Interface
• Realization

50
GoF Structural Patterns

• Adapter
• Bridge
• Composite
• Decorator
• Facade
• Flyweight
• Proxy

51
Adapter

• Context / problemHow to resolve incompatible
  interfaces, or provide a stable interface to
  similar components with different interfaces?
• SolutionConvert the original interface of a
  component into another interface, through an
  intermediate adapter object.

52
Adapter

• Suppose we have a tax calculation class (or
  external library) but the interface is not well
  suited for our application.

53
Adapter

• Adapter providesan interface suitedto the
  application

54
Adapter (For More than One Class)

• What if more than one class (library) needs to be
  adapted?

55
Adapter