Software Engineering Lecture 5: GoF Design Patterns - Behavioral (Memento and Observer), Slides of Software Engineering

Download Software Engineering Lecture 5: GoF Design Patterns - Behavioral (Memento and Observer) and more Slides Software Engineering in PDF only on Docsity!

Patterns inSoftware EngineeringSoftware Engineering Lecturer: Raman RamsinLecturer:^ Raman RamsinLecture 5^ GoF Design Patterns – Behavioral

P^ t 2

Department of Computer Engineering

Sharif University of Technology^1

Part 2

Patterns in Software Engineering – Lecture 5 Memento „ Intent:^

^ Without violating encapsulation, capture and externalize anobject's internal state so that the object can be restored tothis state later. „ Applicability:U^ th^ M^ t

tt^ h

Use the Memento pattern when „ a snapshot of (some portion of) an object's state mustbe saved so that it can be restored to that state later,dand „ a direct interface to obtaining the state would exposeimplementation details and break the object'sl ti

Department of Computer Engineering encapsulation.^ Sharif University of Technology^2

Patterns in Software Engineering – Lecture 5 Memento: Structure Department of Computer Engineering^

Sharif University of Technology 3

Patterns in Software Engineering – Lecture 5 Memento: Collaboration Department of Computer Engineering^

Sharif University of Technology 4

Patterns in Software Engineering – Lecture 5 Memento: Consequences 9 Preserving encapsulation boundaries. The pattern shields otherobjects from potentially complex Originator internalsobjects from potentially complex Originator internals. 9 It simplifies Originator. Having clients manage the state they ask forsimplifies Originator and keeps clients from having to notifyoriginators when they're done.originators when they re done. 8 Using mementos might be expensive. Mementos might incurconsiderable overhead if Originator must copy large amounts ofconsiderable overhead if Originator must copy large amounts ofinformation to store in the memento or if clients create and returnmany mementos. 8 Defining narrow and wide interfaces.

It may be difficult in some

Defining^ narrow and wide interfaces. It may be difficult in somelanguages to ensure that only the originator can access thememento's state. 8 Hidden costs in caring for mementos.Department of Computer Engineering^

g Sharif University of Technology^5

Patterns in Software Engineering – Lecture 5 Observer „ Intent:^

^ Define a one-to-many dependency between objects so that

y^ p^ y^

j when one object changes state, all its dependents are notifiedand updated automatically. Department of Computer Engineering^

Sharif University of Technology 6

Patterns in Software Engineering – Lecture 5 Observer: Applicability „ Use the Observer pattern when„ Use^ the Observer pattern when^

^ an abstraction has two aspects, one dependent on the other.Encapsulating these aspects in separate objects lets you varyEncapsulating these aspects in separate objects lets you varyand reuse them independently.^ ^ a change to one object requires changing others

and you don't

^ a change to one object requires changing others, and you don tknow how many objects need to be changed. ^ an object should be able to notify other objects without making ^ an object should be able to notify other objects without makingassumptions about who these objects are. In other words, youdon't want these objects tightly coupled.Department of Computer Engineering^

Sharif University of Technology 7

Patterns in Software Engineering – Lecture 5 Observer: Structure Department of Computer Engineering^

Sharif University of Technology 8

Patterns in Software Engineering – Lecture 5 Observer: Collaboration Department of Computer Engineering^

Sharif University of Technology 9

Patterns in Software Engineering – Lecture 5 Observer: Consequences 9 Abstract coupling between Subject and Observer 9 Abstract^ coupling between Subject and Observer. 9 Support for broadcast communication. The notification isbroadcast automatically to all interested objects thatb oadcast auto^ at ca y to a

te ested objects t at

subscribed to it. 8 Unexpected updates^

Because observers have no knowledge

8 Unexpected updates. Because observers have no knowledgeof each other's presence, they can be blind to the ultimatecost of changing the subject.^8 A seemingly innocuous operation on the subject may cause acascade of updates to observers and their dependent objects.Department of Computer Engineering

Sharif University of Technology^10

Patterns in Software Engineering – Lecture 5 State „ Intent:^

^ All^ bj^ t t^

lt^ it^ b h^ i^ h^ it

i t^ l^ t t

^ Allow an object to alter its behavior when its internal statechanges. The object will appear to change its class. Department of Computer Engineering^

Sharif University of Technology 11

Patterns in Software Engineering – Lecture 5 State: Applicability^ U^ th^ St t^

tt^ h „^ Use the State pattern when^ ^ An object's behavior depends on its state

and it

^ An object's behavior depends on its state, and itmust change its behavior at run-time depending onthat state. ^ Operations have large, multipart conditionalstatements that depend on the object's statestatements that depend on the object's state.Department of Computer Engineering^

Sharif University of Technology 12

Patterns in Software Engineering – Lecture 5 State: Structure Department of Computer Engineering^

Sharif University of Technology 13

Patterns in Software Engineering – Lecture 5 State: Consequences 9 It localizes state-specific behavior and partitions behaviorfor different states. New states and transitions can beadded easily by defining new subclassesadded easily by defining new subclasses. 9 k

l 9 It makes state transitions explicit. 9 State objects can be shared.Department of Computer Engineering

Sharif University of Technology^14

Patterns in Software Engineering – Lecture 5 Strategy „ Intent:^

^ Define a family of algorithms, encapsulate each one, and makey^

g^ ,^ p^

,

them interchangeable. Strategy lets the algorithm varyindependently from clients that use it. Department of Computer Engineering^

Sharif University of Technology 15

Patterns in Software Engineering – Lecture 5 Strategy: Applicability „ Use the Strategy pattern when^

^ many related classes differ only in their behavior. Strategiesprovide a way to configure a class with one of many behaviors.^ ^ you need different variants of an algorithm. For example, youmight define algorithms reflecting different space/time trade-offs.^ ^ an algorithm uses data that clients shouldn't know about. Usethe Strategy pattern to avoid exposing complex, algorithm-specific data structuresspecific data structures.^ ^ a class defines many behaviors, and these appear as multipleconditional statements in its operations.Department of Computer Engineering^

Sharif University of Technology 16

Patterns in Software Engineering – Lecture 5 Strategy: Structure Department of Computer Engineering^

Sharif University of Technology 17

Patterns in Software Engineering – Lecture 5 Strategy: Consequences 9 Families of related algorithms.g 9 An alternative to subclassing. 9 Strategies eliminate conditional statements. 9 A choice of implementations. Strategies can provide differentimplementations of the

same behavior. The client can choose

among strategies with different time and space trade-offs. 8 Clients must be aware of different Strategies. 8 Communication overhead between Strategy and Context. 8 Increased number of objects.Department of Computer Engineering^

Sharif University of Technology 18

Patterns in Software Engineering – Lecture 5 Visitor „ Intent:^

^ Represent an operation to be performed on the elements of an objectstructure; lets you define a new operation without changing the;^ y^

p^ g^ g classes of the elements on which it operates. Department of Computer Engineering^

Sharif University of Technology 19

Patterns in Software Engineering – Lecture 5 Visitor: Applicability „ Use the Visitor pattern when^

^ an object structure contains many classes of objects withdiffering interfaces, and you want to perform operationsth^ bj^ t^

th t d^ d^ th i^

t^ l

on these objects that depend on their concrete classes.

many distinct and unrelated operations need to beperformed on objects in an object structure

and you

performed on objects in an object structure, and youwant to avoid "polluting" their classes with theseoperations.

the classes defining the object structure rarely change,but you often want to define new operations over thestructure.Department of Computer Engineering^

Sharif University of Technology 20

structure.

Patterns in Software Engineering – Lecture 5 Visitor: Structure Department of Computer Engineering^

Sharif University of Technology 21

Patterns in Software Engineering – Lecture 5 Visitor: Collaborations Department of Computer Engineering^

Sharif University of Technology 22

Patterns in Software Engineering – Lecture 5 Visitor: Consequences 9 Visitor makes adding new operations easy 9 Visitor^ makes adding new operations easy. 9 A visitor gathers related operations and separatesunrelated ones.unrelated ones. 8 Adding new ConcreteElement classes is hard 8 Adding new ConcreteElement classes is hard. 8 Breaking encapsulation. The pattern often forces you toprovide public operations that access an element'sprovide public operations that access an element sinternal state, which may compromise its encapsulation.Department of Computer Engineering^

Sharif University of Technology 23

Patterns in Software Engineering – Lecture 5 ReferenceReference^ G^ E^ H l^

R^ J h^ R^ d Vli

id^ J^ D^ i „^ Gamma, E., Helm, R., Johnson, R., and Vlissides, J.,

Design Patterns: Elements of Reusable Object-oriented Software.Addison-Wesley, 1995.Department of Computer Engineering^

Sharif University of Technology 24