1. CS 5150 1 CS 5150 Software Engineering Lecture 16 Object Oriented Design 2

2. CS 5150 2 Administration Test 3: Monday October 25 Test 3 is this evening. Each test covers material from all the lectures, up to and including the previous class. Assignments 3 & 4: Presentations Sign up a time for your presentations. Time slots are on the web site.

3. CS 5150 3 Answering the Tests Read the question carefully. Words in bold, italic, or underlined are intended to help you, e.g., as hints Structure you answer to follow the structure of the question.

4. CS 5150 4 Answering the Tests: Test 1, Question 2 You are asked to recommend a software development process for the proposed extension to the WYX system. (a)i Is the modified waterfall model a good choice for developing this system? ii Give two reasons for your answer. Template for answer (a)i["Yes" or "No"] ii"1." [Reason 1] "2." [Reason 2]

5. CS 5150 5 Answering the Tests: Test 1, Question 2 (continued) (d)What software development process would you recommend? Template for answer (d) [Name of a process]

6. CS 5150 6 Design Patterns Sources: E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1994 The following discussion of design patterns is based on Gamma, et al., 1994, and Bruegge and Dutoit, 2004. Wikipedia has good discussion of many design patterns, using UML and other notation, with code samples.

7. CS 5150 7 Design Pattern Design patterns are template designs that can be used in a variety of systems. They are particularly appropriate in situations where classes are likely to be reused in a system that evolves over time. Name. [Some of the names used by Gamma, et al. have become standard software terminology.] Problem description. Describes when the pattern might be used, often in terms of modifiability and extensibility. Solution. Expressed in terms of classes and interfaces. Consequences. Trade-offs and alternatives.

8. CS 5150 8 Notation ClassNameclass name in italic indicates an abstract class dependency delegation inheritance whole/part association wholepart

9. CS 5150 9 Facade: Encapsulating Subsystems Name: Facade design pattern Problem description: Reduce coupling between a set of related classes and the rest of the system. Solution: A single Facade class implements a high-level interface for a subsystem by invoking the methods of the lower-level classes. Example. A Compiler is composed of several classes: LexicalAnalyzer, Parser, CodeGenerator, etc. A caller invokes only the Compiler (Facade) class, which invokes the contained classes.

10. CS 5150 10 Facade: Class Diagram Facade service() Class1 service1() Class2 service2() Class3 service3() Facade

11. CS 5150 11 Facade: Consequences Consequences: Shields a client from the low-level classes of a subsystem. Simplifies the use of a subsystem by providing higher-level methods. Enables lower-level classes to be restructured without changes to clients. Note. The repeated use of Facade patterns yields a layered system.

12. CS 5150 12 Adapter (Wrapper): Wrapping Around Legacy Code Problem description: Convert the interface of a legacy class into a different interface expected by the client, so that the client and the legacy class can work together without changes. This problem often occurs during a transitional period, when the long-term plan is to phase out the legacy system. Example: How do you use a web browser to access an information retrieval system that was designed for a different client?

13. CS 5150 13 Adapter Design Pattern: The Problem LegacyClass existingRequest() NewClient OldClient NewClass request() dependency During the transition, how can NewClient be used with LegacyClass?

14. CS 5150 14 Adapter Design Pattern: Solution Class Diagram ClientInterface request() Adapter request() LegacyClass existingRequest() Client abstract class shown in italic delegation inheritance

15. CS 5150 15 Adapter Design Pattern: Consequences The following consequences apply whenever the Adapter design pattern is used. Client and LegacyClass work together without modification of either. Adapter works with LegacyClass and all of its subclasses. A new Adapter needs to be written if Client is replaced by a subclass.

16. CS 5150 16 Bridge: Allowing for Alternate Implementations Name: Bridge design pattern Problem description: Decouple an interface from an implementation so that a different implementation can be substituted, possibly at runtime (e.g., testing different implementations of the same interface).

17. CS 5150 17 Bridge: Class Diagram Client ConcreteImplementorA ConcreteImplementorB alternative implementations

18. CS 5150 18 Bridge: Class Diagram Implementor Client ConcreteImplementorA ConcreteImplementorB

19. CS 5150 19 Bridge: Class Diagram AbstractionImplementor Client ConcreteImplementorA ConcreteImplementorB whole/part association Note the similarity to the strategy design pattern (described later)

20. CS 5150 20 Bridge: Allowing for Alternate Implementations Solution: The Abstraction class defines the interface visible to the client. Implementor is an abstract class that defines the lower-level methods available to Abstraction. An Abstraction instance maintains a reference to its corresponding Implementor instance. Abstraction and Implementor can be refined independently.

21. CS 5150 21 Bridge: Class Diagram Abstraction RefinedAbstraction Implementor Client ConcreteImplementorA ConcreteImplementorB new abstraction

22. CS 5150 22 Bridge: Consequences Consequences: Client is shielded from abstract and concrete implementations Interfaces and implementations may be tested separately

23. CS 5150 23 Strategy: Encapsulating Algorithms Name: Strategy design pattern Problem description: Decouple a policy-deciding class from a set of mechanisms, so that different mechanisms can be changed transparently. Example: A mobile computer can be used with a wireless network, or connected to an Ethernet, with dynamic switching between networks based on location and network costs.

24. CS 5150 24 Strategy Example: Class Diagram for Mobile Computer NetworkInterface open() close() send() Application Ethernet open() close() send() WirelessNet open() close() send()

25. CS 5150 25 Strategy Example: Class Diagram for Mobile Computer NetworkConnection open() close() send() setNetworkInterface() NetworkInterface open() close() send() ApplicationLocationManager Ethernet open() close() send() WirelessNet open() close() send() use location information to select network

26. CS 5150 26 Strategy: Class Diagram Context contextInterface() Strategy algorithmInterface() Client ConcreteStrategy2 Policy ConcreteStrategy1 Policy class selects ConcreteStrategy Note the similarity to the bridge design pattern (described above)

27. CS 5150 27 Strategy: Encapsulating Algorithms Solution: A Client accesses services provided by a Context. The Context services are realized using one of several mechanisms, as decided by a Policy object. The abstract class Strategy describes the interface that is common to all mechanisms that Context can use. Policy class creates a ConcreteStrategy object and configures Context to use it.

28. CS 5150 28 Strategy: Consequences Consequences: ConcreteStrategies can be substituted transparently from Context. Policy decides which Strategy is best, given the current circumstances. New policy algorithms can be added without modifying Context or Client.

29. CS 5150 29 Composite: Representing Recursive Hierarchies Name: Composite design pattern Problem description: Represent a hierarchy of variable width and depth, so that the leaves and composites can be treated uniformly through a common interface.

30. CS 5150 30 Composite: Class Diagram Composite Leaf Component * Client

31. CS 5150 31 Composite: Representing Recursive Hierarchies Solution: The Component interface specifies the services that are shared between Leaf and Composite. A Composite has an aggregation association with Components and implements each service by iterating over each contained Component. The Leaf services do the actual work.

32. CS 5150 32 Composite: Consequences Consequences: Client uses the same code for dealing with Leaves or Composites. Leaf-specific behavior can be changed without changing the hierarchy. New classes of Leaves can be added without changing the hierarchy.

33. CS 5150 33 Proxy: Encapsulating Expensive Objects Name: Proxy design pattern Problem description: Improve performance or security of a system by delaying expensive computations, using memory only when needed, or checking access before loading an object into memory. Solution: The ProxyObject class acts on behalf of a RealObject class. Both implement the same interface. ProxyObject stores a subset of the attributes of RealObject. ProxyObject handles certain requests, whereas others are delegated to RealObject. After delegation, the RealObject is created and loaded into memory.

34. CS 5150 34 Proxy: Example An abstract class SortStrings defines an interface for sorting lists of strings. ProxySortStrings is a class that sorts lists of strings very quickly in memory and delegates larger lists. RealSortStrings is a class that sorts very large lists of strings, but is expensive to create and execute on small lists.

35. CS 5150 35 Proxy: Class Diagram Object filename op1() op2() RealObject data:byte[] op1() op2() ProxyObject filename op1() op2() 1 0..1 Client

36. CS 5150 36 Proxy: Consequences Consequences: Adds a level of indirection between Client and RealObject. The Client is shielded from any optimization for creating RealObjects.

37. CS 5150 37 Abstract Factory: Encapsulating Platforms Name: Abstract Factory design pattern Problem description: Shield the client from different platforms that provide different implementations of the same set of concepts Example: A user interface must have versions that implement the same set of concepts for several windowing systems, e.g., scroll bars, buttons, highlighting, etc.

38. CS 5150 38 Abstract Factory: Encapsulating Platforms Solution: A platform (e.g., the application for a specific windowing system) is represented as a set of AbstractProducts, each representing a concept (e.g., button). An AbstractFactory class declares the operations for creating each individual product. A specific platform is then realized by a ConcreteFactory and a set of ConcreteProducts.

39. CS 5150 39 Abstract Factory: Class Diagram ClientAbstractFactory createProductA createProductB AbstractProductA AbstractProductB

40. CS 5150 40 Abstract Factory: Class Diagram ClientAbstractFactory createProductA ConcreteFactory1 createProductA AbstractProductA ProductA There could be several ConcreteFactory classes, each a subclass of AbstractFactory,

41. CS 5150 41 Abstract Factory: Class Diagram ClientAbstractFactory createProductA createProductB ConcreteFactory1 createProductA createProductB AbstractProductA ProductA There could be several ConcreteFactory classes, each a subclass of AbstractFactory. AbstractProductB ProductB

42. CS 5150 42 Abstract Factory: Consequences Consequences: Client is shielded from concrete products classes Substituting families at runtime is possible Adding new products is difficult since new realizations must be created for each factory

43. CS 5150 43 Abstract Factory: Discussion Discussion See the interesting discussion in Wikipedia (October 25, 2010): "Use of this pattern makes it possible to interchange concrete classes without changing the code that uses them, even at runtime. However, employment of this pattern, as with similar design patterns, may result in unnecessary complexity and extra work in the initial writing of code."

44. CS 5150 44 Command: Encapsulating Control Flow Name: Command design pattern Problem description: Encapsulates requests so that they can be executed, undone, or queued independently of the request. Solution: A Command abstract class declares the interface supported by all ConcreteCommands. ConcreteCommands encapsulate a service to be applied to a Receiver.

45. CS 5150 45 Command: Class Diagram Receiver1 Command execute() ConcreteCommand1 execute() Invoker invokes

46. CS 5150 46 Command Example: Class Diagram for Match GameBoard Move play() replay() GameMove play() replay() Match invokes

47. CS 5150 47 Command: Consequences Consequences: The object of the command (Receiver) and the algorithm of the command (ConcreteCommand) are decoupled. Invoker is shielded from specific commands. ConcreteCommands are objects. They can be created and stored. New ConcreteCommands can be added without changing existing code.

48. CS 5150 48 Observer: Encapsulating Control Flow Name: Observer design pattern Problem description: Maintains consistency across state of one Subject and many Observers. Solution: A Subject has a primary function to maintain some state (e.g., a data structure). One or more Observers use this state, which introduces redundancy between the states of Subject and Observer. Observer invokes the subscribe() method to synchronize the state. Whenever the state changes, Subject invokes its notify() method to iteratively invoke each Observer.update() method.

49. CS 5150 49 Observer: Class Diagram Subject subscribe() unsubscribe() notify() subscribers ConcreteSubject state getstate() setstate() Observer update() ConcreteObserver observeState update() 1 *

50. CS 5150 50 Observer: Consequences Consequences: Decouples Subject, which maintains state, from Observers, who make use of the state. Can result in many spurious broadcasts when the state of Subject changes.