SOEN 343 Software Design Section H Fall 2006 Dr Greg Butler

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

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

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

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

Fig

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

Patterns and Principles We have (and still are) studying: Larman’s GRASP GoF Fowler’s EA The most fundamental are the principles.

GRASP: Interrelationships

Patterns apply principles, e.g. …

Gang Of Four Gamma, Helm, Johnson, Vlissides Some patterns in Larman, Chap. 23,… All patterns in XDE –As documentation. –As dynamic templates.

Present solutions to common software problems arising within a certain context Overview of Patterns Capture recurring structures & dynamics among software participants to facilitate reuse of successful designs The Proxy Pattern 11 Proxy service Service service AbstractService service Client Help resolve key software design forces Flexibility Extensibility Dependability Predictability Scalability Efficiency Generally codify expert knowledge of design strategies, constraints & “best practices”

GoF Pattern Summary & Relationships

GoF Pattern Classification Behavioral Patterns Creational Patterns Structural Patterns

GoF Behavioral Patterns Chain of Responsibility Command Interpreter Iterator Mediator Memento Observer State Strategy Template Method Visitor

GoF Creational Patterns Abstract Factory Builder Factory Method Prototype Singleton

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

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

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?

Converting C to a Singleton.

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.

«Singleton» C.getUniqueInstance() public static C getUniqueInstance() { if(uniqueInstance == null) { uniqueInstance = new C(); } return uniqueInstance; }

Thread-safe Creation Method public static synchronized C getUn…() { … }

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 > 1). Subclassing. Passing the instance as a parameter. … (See Larman05, Section 26.5)

Singleton: Design Issues (Cont’d) See Larman05, Section 26.5 for discussion of –Design trade-offs, including eager/lazy evaluation of Singleton.uniqueInstance see.

Singleton & UML

Dice Game Simple game: Player rolls a dice Score is the face value of the dice

Client Cannot Tell …

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.

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.

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.

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()); }

Factory Context / problem: Who 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? Solution: Create a Pure Fabrication object called a Factory.

Factory Example

Larman’s 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

(Abstract) Factory Example (GoF)

Factory (in EAs) FrontCommand + init ( ) + processRequest ( ) ViewStudInfoCommand + processRequest ( ) RemoveStudentCommand + processRequest ( ) FrontControllerServlet # processRequest ( ) - getCommand ( ) : FrontCommand - getCommandClass ( )

New Version of Dice Game Support using a pair of Dice. How can this be added?

Multi-Dice Design

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.

Dice Composite

Client Cannot Tell …

Composite: Ex. Objects

Composite: Ex. Class Diagram

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?

Composite: Clients point-of-view

Composite Pricing Strategies Interface Realization

GoF Structural Patterns Adapter Bridge Composite Decorator Facade Flyweight Proxy

Adapter Context / problem How to resolve incompatible interfaces, or provide a stable interface to similar components with different interfaces? Solution: Convert the original interface of a component into another interface, through an intermediate adapter object.

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

Adapter Adapter provides an interface suited to the application GoodAsGoldTaxProAdapter getTaxes( Sale ) : List of TaxLineItems computeTax(…):double GoodAsGoldTaxPro

Adapter (For More than One Class) What if more than one class (library) needs to be adapted?

Adapter