Design Patterns in Software Engineering, Lecture notes of Compiler Design

Download Design Patterns in Software Engineering and more Lecture notes Compiler Design in PDF only on Docsity!

Cornell University

Compu1ng and Informa1on Science

CS 5150 So(ware Engineering

Design Pa4erns

William Y. Arms

Design Pa4erns

Sources: E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Pa*erns: Elements of Reusable Object-­‐Oriented So<ware. Addison-­‐Wesley, 1994 The following discussion of design pa4erns is based on Gamma, et al., 1994, and Bruegge and Dutoit, 2004. Wikipedia has good discussion of many design pa4erns, using UML and other notaTon, with code samples.

Design Pa4ern

Design pa;erns are template designs that can be used in a variety of systems. They are parTcularly appropriate in situaTons where classes are likely to be reused in a system that evolves over Tme.

• Name [Some of the names used by Gamma, et al. have become standard so(ware terminology.]
• Problem descripTon Describes when the pa4ern might be used, o(en in terms of modifiability and extensibility.
• SoluTon Expressed in terms of classes and interfaces.
• Consequences Trade-­‐offs and alternaTves.

NotaTon

ClassName class name in italic indicates an abstract class dependency delegaTon inheritance whole/part associaTon whole part

Abstract Classes

Abstract class Abstract classes are superclasses which contain abstract methods and are defined such that concrete subclasses extend them by implemenTng the methods. Before a class derived from an abstract class can become concrete, i.e. a class that can be instanTated, it must implement parTcular methods for all the abstract methods of its parent classes. The incomplete features of an abstract class are shared by a group of subclasses which add different variaTons of the missing pieces. Wikipedia 4/2/

Adapter (Wrapper): Wrapping Around Legacy Code

Problem descrip1on: 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 o(en occurs during a transiTonal period, when the long-­‐ term plan is to phase out the legacy system. Example: How do you use a web browser to access an informaTon retrieval system that was designed for a different client?

Adapter Design Pa4ern: The Problem

LegacyClass exisTngRequest() NewClient OldClient NewClass request() dependency During the transiTon, how can NewClient be used with LegacyClass?

Adapter Design Pa4ern: SoluTon Class Diagram

ClientInterface request() Adapter request() LegacyClass exisTngRequest() Client abstract class shown in italic delegaTon inheritance

Adapter Design Pa4ern: Consequences

The following consequences apply whenever the Adapter design pa4ern is used.

• Client and LegacyClass work together without modificaTon of either.
• Adapter works with LegacyClass and all of its subclasses.
• A new Adapter needs to be wri4en if Client is replaced by a subclass.

Bridge: Allowing for Alternate ImplementaTons

Name: Bridge design pa4ern Problem descrip1on: Decouple an interface from an implementaTon so that a different implementaTon can be subsTtuted, possibly at runTme (e.g., tesTng different implementaTons of the same interface).

Bridge: Class Diagram

Client ConcreteImplementorA ConcreteImplementorB alternaTve implementaTons

Bridge: Class Diagram

Implementor Client ConcreteImplementorA ConcreteImplementorB

Bridge:

Class Diagram

AbstracTon Implementor Client ConcreteImplementorA ConcreteImplementorB whole/part associaTon Note the similarity to the strategy design pa4ern (described later)

Bridge: Allowing for Alternate ImplementaTons

Solu1on: The AbstracTon class defines the interface visible to the client. Implementor is an abstract class that defines the lower-­‐level methods available to AbstracTon. An AbstracTon instance maintains a reference to its corresponding Implementor instance. AbstracTon and Implementor can be refined independently.

Bridge:

Class Diagram

AbstracTon RefinedAbstracTon Implementor Client ConcreteImplementorA ConcreteImplementorB new abstracTon

Bridge: Consequences

Consequences: Client is shielded from abstract and concrete implementaTons Interfaces and implementaTons can be tested separately

Strategy: EncapsulaTng Algorithms

Name: Strategy design pa4ern Example: A mobile computer can be used with a wireless network, or connected to an Ethernet, with dynamic switching between networks based on locaTon and network costs. Problem descrip1on: Decouple a policy-­‐deciding class from a set of mechanisms, so that different mechanisms can be changed transparently.

Strategy Example: Class Diagram for Mobile Computer

NetworkInterface open() close() send() ApplicaTon Ethernet open() close() send() WirelessNet open() close() send()

Strategy Example: Class Diagram for Mobile Computer

NetworkConnecTon open() close() send() setNetworkInterface() NetworkInterface open() close() send() ApplicaTon LocaTonManager Ethernet open() close() send() WirelessNet open() close() send() use locaTon informaTon to select network

Strategy: EncapsulaTng Algorithms

Solu1on: 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.

Strategy: Class Diagram

Context contextInterface() Strategy algorithmInterface() Client ConcreteStrategy2 Policy ConcreteStrategy1 Policy class selects ConcreteStrategy Note the similarity to the bridge design pa4ern (described above)

Strategy: Consequences

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

Facade: EncapsulaTng Subsystems

Name: Facade design pa4ern Problem descrip1on: Reduce coupling between a set of related classes and the rest of the system. 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. Solu1on: A single Facade class implements a high-­‐level interface for a subsystem by invoking the methods of the lower-­‐level classes.

Facade: Class Diagram

Facade service() Class1 service1() Class2 service2() Class3 service3() Facade

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 pa4erns yields a layered system.