CS 501: Software EngineeringAdministrationDesign PatternsSourcesDesign PatternAdapter: Wrapping Around Legacy CodeAdapter Design PatternAdapter Design Pattern: Solution Class DiagramAdapter Design Pattern: ConsequencesBridge: Allowing for Alternate ImplementationsBridge: Class DiagramSlide 12Slide 13Slide 14Slide 15Bridge: ConsequencesStrategy: Encapsulating AlgorithmsStrategy Example: Class Diagram for Mobile ComputerSlide 19Strategy: Class DiagramSlide 21Strategy: ConsequencesComposite: Representing Recursive HierarchiesComposite: Class DiagramComposite: ConsequencesAbstract Factory: Encapsulating PlatformsSlide 27Abstract Factory: Class DiagramSlide 29Slide 30Abstract Factory: ConsequencesCommand: Encapsulating Control FlowCommand Example: Class Diagram for MatchCommand: Class DiagramCommand: ConsequencesFacade: Encapsulating SubsystemsFacade: Class DiagramFacade: ConsequencesProxy: Encapsulating Expensive ObjectsProxy: Class DiagramProxy: ConsequencesObserver: Encapsulating Control FlowObserver: Class DiagramObserver: Consequences1CS 501 Spring 2008CS 501: Software EngineeringLectures 17 & 18Object Oriented Design 3 & 42CS 501 Spring 2008AdministrationQuiz 3: Thursday March 27Quiz 3 is on Thursday, March 27.Each quiz covers material from all the lectures, up to and including the previous class. Assignment 3: PresentationSign up a time for your presentation. Time slots are on the web site. No office hours on Thursday, March 273CS 501 Spring 2008Design PatternsDesign patterns:E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 19944CS 501 Spring 2008SourcesThe following discussion of design patterns is based on Gamma, et al., 1994, and Bruegge and Dutoit, 2004.5CS 501 Spring 2008Design PatternDesign 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.6CS 501 Spring 2008Adapter: Wrapping Around Legacy CodeProblem 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?7CS 501 Spring 2008Adapter Design PatternLegacyClassexistingRequest()NewClientOldClientNewClassrequest()dependency8CS 501 Spring 2008Adapter Design Pattern: Solution Class DiagramClientInterfacerequest()Adapterrequest()LegacyClassexistingRequest()Clientabstract classdelegationinheritance9CS 501 Spring 2008Adapter Design Pattern: ConsequencesThe following consequences apply whenever the Adapter design pattern in 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.10CS 501 Spring 2008Bridge:Allowing for Alternate Implementations Name: Bridge design patternProblem 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).11CS 501 Spring 2008Bridge: Class DiagramClientConcreteImplementorAConcreteImplementorBalternative implementations12CS 501 Spring 2008Bridge: Class DiagramImplementorClientConcreteImplementorAConcreteImplementorB13CS 501 Spring 2008Bridge: Class DiagramAbstraction ImplementorClientConcreteImplementorAConcreteImplementorBwhole/part association14CS 501 Spring 2008Bridge: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.15CS 501 Spring 2008Bridge: Class DiagramAbstractionRefinedAbstractionImplementorClientConcreteImplementorAConcreteImplementorBnew abstraction16CS 501 Spring 2008Bridge: ConsequencesConsequences:Client is shielded from abstract and concrete implementationsInterfaces and implementations may be tested separately17CS 501 Spring 2008Strategy:Encapsulating Algorithms Name: Strategy design patternProblem 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.18CS 501 Spring 2008Strategy Example: Class Diagram for Mobile ComputerNetworkInterfaceopen()close()send()ApplicationEthernetopen()close()send()WirelessNetopen()close()send()19CS 501 Spring 2008Strategy Example: Class Diagram for Mobile ComputerNetworkConnectionsend()setNetworkInterface()NetworkInterfaceopen()close()send()Application LocationManagerEthernetopen()close()send()WirelessNetopen()close()send()Note the similarities to Bridge pattern20CS 501 Spring 2008Strategy: Class DiagramContextcontextInterface()StrategyalgorithmInterface()ClientConcreteStrategy2PolicyConcreteStrategy121CS 501 Spring 2008Strategy: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.22CS 501 Spring 2008Strategy: ConsequencesConsequences: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.23CS 501 Spring 2008Composite:Representing Recursive HierarchiesName: Composite design
View Full Document
Unlocking...