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 14Bridge: ConsequencesStrategy: Encapsulating AlgorithmsStrategy: Class DiagramSlide 18Strategy Example: Class Diagram for Mobile ComputerStrategy: ConsequencesAbstract Factory: Encapsulating PlatformsAbstract Factory: Class DiagramSlide 23Abstract Factory: ConsequencesCommand: Encapsulating Control FlowCommand: Class DiagramCommand: Class Diagram for MatchCommand: ConsequencesComposite: Representing Recursive HierarchiesComposite: Class DiagramComposite: ConsequencesFacade: Encapsulating SubsystemsFacade: Class DiagramFacade: ConsequencesObserver: Encapsulating Control FlowObserver: Class DiagramObserver: ConsequencesProxy: Encapsulating Expensive ObjectsProxy: Class DiagramProxy: Consequences1CS 501 Spring 2006CS 501: Software EngineeringLecture 18Object Oriented Design 42CS 501 Spring 2006Administration3CS 501 Spring 2006Design PatternsDesign patterns:E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 19944CS 501 Spring 2006SourcesThe following discussion of design patterns is based on Gamma, et al., 1994, and Bruegge and Dutoit, 2004.5CS 501 Spring 2006Design 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. are becoming 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 2006Adapter: Wrapping Around Legacy CodeProblem description: Convert the user 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 existing information retrieval system that was designed for a different client?7CS 501 Spring 2006Adapter Design PatternLegacyClassexistingRequest()NewClientOldClientNewClassrequest()dependency8CS 501 Spring 2006Adapter Design Pattern: Solution Class DiagramClientInterfacerequest()Adapterrequest()LegacyClassexistingRequest()Clientabstract classdelegationinheritance9CS 501 Spring 2006Adapter 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 2006Bridge: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 2006Bridge: Class DiagramClientConcreteImplementorAConcreteImplementorBalternative implementations12CS 501 Spring 2006Bridge: Class DiagramAbstraction ImplementorClientConcreteImplementorAConcreteImplementorBwhole/part association13CS 501 Spring 2006Bridge: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.14CS 501 Spring 2006Bridge: Class DiagramAbstractionRefinedAbstractionImplementorClientConcreteImplementorAConcreteImplementorBnew abstraction15CS 501 Spring 2006Bridge: ConsequencesConsequences:Client is shielded from abstract and concrete implementationsInterfaces and implementations may be tested separately16CS 501 Spring 2006Strategy: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.17CS 501 Spring 2006Strategy: Class DiagramContextcontextInterface()StrategyalgorithmInterface()ClientConcreteStrategy2PolicyConcreteStrategy118CS 501 Spring 2006Strategy: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.19CS 501 Spring 2006Strategy 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 2006Strategy: 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.21CS 501 Spring 2006Abstract Factory: Encapsulating PlatformsName: Abstract Factory design patternProblem description: Shield the client from different platforms that provide different implementations of the same set of conceptsExample: A browser must have versions that implement the same set of concepts for several windowing systems, e.g., scroll bars, buttons, highlighting, etc.22CS 501 Spring 2006Abstract Factory: Class DiagramClient AbstractFactorycreateProductA createProductBConcreteFactory1createProductA createProductBAbstractProductAProductAClasses for ProductB are not shown in this diagram.There could be several ConcreteFactory classes, each a subclass of
View Full Document
Unlocking...