softwaretechnologie für fortgeschrittene teil thaller stunde v: software engineering ii köln 28....
Post on 21-Dec-2015
214 views
TRANSCRIPT
Softwaretechnologie für FortgeschritteneTeil Thaller
Stunde V: Software Engineering II
Köln 28. Januar 2010
Design Patterns
2
(1) Eine „Kunstlehre“, die auf der Objektorientierung aufsetzt ...
(2) … so verbreitet, dass ich mir erlaubt habe, zwei sehr geringfügig modifizierte Vorlesungsfolien auswärtiger Kollegen zu benutzen.
Design PatternsCS 406 Software Engineering I
Fall 2001
Aditya P. Mathur
Purdue University
October 30, 2001
CS 406: Design Patterns 4
Organization
Patterns:
Behavioral:Observer
Structural:Façade
Creational Abstract FactoryFactory MethodSingleton
Excellent reference:
Design Patterns book by Erich Gamma, et al., Addison-Wesley, 1994.
CS 406: Design Patterns 5
Design Patterns [1]
• A solution to a problem that occurs repeatedly in a variety of contexts.
• Each pattern has a name.
• Use of each pattern has consequences.
CS 406: Design Patterns 6
Design Patterns [2]
• Generally at a “higher level” of abstraction.
• Not about designs such as linked lists or hash tables.
• Generally descriptions of communicating objects and classes.
CS 406: Design Patterns 7
Observer Pattern [1]
• Need to separate presentational aspects with the data, i.e. separate views and data.
• Classes defining application data and presentation can be reused.
• Change in one view automatically reflected in other views. Also, change in the application data is reflected in all views.
• Defines one-to-many dependency amongst objects so that when one object changes its state, all its dependents are notified.
CS 406: Design Patterns 8
Observer Pattern [2]
A=10%B=40%C=30%D=20%
Application data
A
BC
D
A DCB
Relative Percentages
Y 10 40 30 20
X 15 35 35 15
Z 10 40 30 20
A B C D
Change notification
Requests, modifications
CS 406: Design Patterns 9
Observer Pattern [3]
Subject
attach (Observer)
detach (Observer)
Notify ()
Observer
Update()
Concrete Observer
Update()
observerState
Concrete Subject
GetState()
SetState()
subjectState
observers
subject
For all x in observers{ x Update(); }
observerState= subject getState();
CS 406: Design Patterns 10
Class collaboration in Observer
:ConcreteSubject :ConcreteObserver-1 :ConcreteObserver-2
GetState()
Notify()
Update()
SetState()
GetState()
Update()
CS 406: Design Patterns 11
Observer Pattern: Observer code
class Subject;
class observer {public:
virtual ~observer;
protected:
virtual void Update (Subject* theChangedSubject)=0;
observer ();
Note the support for multiple subjects.};
Abstract class definingthe Observer interface.
CS 406: Design Patterns 12
Observer Pattern: Subject Code [1]
class Subject {
public:
virtual ~Subject;
protected:
Subject ();
virtual void Attach (observer*);
virtual void Detach (observer*) ;
virtual void Notify();
private:
List <Observer*> *_observers;
};
Abstract class definingthe Subject interface.
CS 406: Design Patterns 13
Observer Pattern: Subject Code [2]
void Subject :: Attach (Observer* o){
_observers -> Append(o);}
void Subject :: Detach (Observer* o){
_observers -> Remove(o);
}
void Subject :: Notify (){
ListIterator<Observer*> iter(_observers);
}
for ( iter.First(); !iter.IsDone(); iter.Next()) {
iter.CurrentItem() -> Update(this);
}
CS 406: Design Patterns 14
Observer Pattern: A Concrete Subject [1]
class ClockTimer : public Subject {
public:
virtual int GetHour();
}
virtual int GetMinutes();
virtual int GetSecond();
ClockTimer();
void Tick ();
CS 406: Design Patterns 15
Observer Pattern: A Concrete Subject [2]
ClockTimer :: Tick {
// Update internal time keeping state.// gets called on regular intervals by an internal timer.
}
Notify();
CS 406: Design Patterns 16
Observer Pattern: A Concrete Observer [1]
class DigitalClock: public Widget, public Observer {
public:
DigitalClock(ClockTimer*);
virtual ~DigitalClock();
virtual void Draw();
private:
}
ClockTimer* _subject;
virtual void Update(Subject*);Override Observer operation.
Override Widget operation.
CS 406: Design Patterns 17
Observer Pattern: A Concrete Observer [2]
DigitalClock ::DigitalClock (ClockTimer* s) {
_subject = s;
}
_subjectAttach(this);
DigitalClock ::~DigitalClock() {
_subject->Detach(this);
}
CS 406: Design Patterns 18
Observer Pattern: A Concrete Observer [3]
void DigitalClock ::Update (subject* theChangedSubject ) {
If (theChangedSubject == _subject) {
}
Draw();}
void DigitalClock ::Draw () {
int hour = _subject->GetHour();
}
int minute = _subject->GeMinute(); // etc.
Check if this is the clock’s subject.
// Code for drawing the digital clock.
CS 406: Design Patterns 19
Observer Pattern: Main (skeleton)
ClockTimer* timer = new ClockTimer;
DigitalClock* digitalClock = new DigitalClock (timer);
CS 406: Design Patterns 20
When to use the Observer Pattern?
• When an abstraction has two aspects: one dependent on the other. Encapsulating these aspects in separate objects allows one to vary and reuse them independently.
• When a change to one object requires changing others and the number of objects to be changed is not known.
• When an object should be able to notify others without knowing who they are. Avoid tight coupling between objects.
CS 406: Design Patterns 21
Observer Pattern: Consequences
• Abstract coupling between subject and observer. Subject has no knowledge of concrete observer classes. (What design principle is used?)
• Support for broadcast communication. A subject need not specify the receivers; all interested objects receive the notification.
• Unexpected updates: Observers need not be concerned about when then updates are to occur. They are not concerned about each other’s presence. In some cases this may lead to unwanted updates.
CS 406: Design Patterns 22
Facade Pattern: Problem
Client Classes
Subsystem classes
Need to communicatewith
CS 406: Design Patterns 23
Facade Pattern: Solution
Client Classes
Subsystem classes
Facade
CS 406: Design Patterns 24
Facade Pattern: Why and What?
• Need to provide a simple interface to many, often small, classes. But not necessarily to ALL classes of the subsystem.
• Façade provides a simple default view good enough for most clients.
• Facade decouples a subsystem from its clients.
• Subsystems often get complex as they evolve.
• A façade can be a single entry point to each subsystem level. This allows layering.
CS 406: Design Patterns 25
Facade Pattern: Participants and Communication
• Clients communicate with subsystem classes by sending requests to façade.
• Façade forwards requests to the appropriate subsystem classes.
• Clients do not have direct access to subsystem classes.
• Participants: Façade and subsystem classes
CS 406: Design Patterns 26
Facade Pattern: Benefits
• Promotes weak coupling between subsystem and its clients.
• Helps in layering the system. Helps eliminate circular dependencies.
• Shields clients from subsystem classes; reduces the number of objects that clients deal with.
CS 406: Design Patterns 27
Example: A compiler
StackMachineCodegeneratorRISCCodegenerator
Stream
BytecodeStream
CodeGenerator
Scanner Token
Parser Symbol
PnodeBuilder Pnode
ExpressionNodeStatementNode
CompilerCompile()
Invocations
CS 406: Design Patterns 28
Façade Pattern: Code [1]class Scanner {
public:
Scanner (istream&);
Private:
virtual Scanner();
istream& _inputStream;
};
virtual Token& Scan();
// Takes a stream of characters and produces a stream of tokens.
CS 406: Design Patterns 29
Façade Pattern: Code [2]class parser {
public:
Parser ();
virtual ~Parser()
};
virtual void Parse (Scanner&, PNodeBuilder&);
// Builds a parse tree from tokens using the PNodeBuilder.
CS 406: Design Patterns 30
Façade Pattern: Code [3]class Pnodebuilder {
public:
Pnodebuilder ();
virtual Pnode* NewVariable (
) const;
Char* variableName
// Builds a parse tree incrementally. Parse tree // consists of Pnode objects.
virtual Pnode* NewAssignment (
) const;
Pnode* variable, Pnode* expression
// Node for a variable.
// Node for an assignment.
// Similarly...more nodes.Private:
Pnode* _node;
};
CS 406: Design Patterns 31
Façade Pattern: Code [4]class Pnode {
public:
// An interface to manipulate the program node and its children.
PNode();
protected:
};
virtual void GetSourcePosition (int& line, int& index);
// Manipulate program node.
virtual void Add (Pnode*);
// Manipulate child node.
virtual void Remove (Pnode*);// ….
virtual void traverse (Codegenerator&); // Traverse tree to generate code.
CS 406: Design Patterns 32
Façade Pattern: Code [5]class CodeGenerator {
public:
// Generate bytecode.
virtual void Visit (StatementNode*);
// Manipulate program node.
// ….
virtual void Visit (ExpressionNode*);
Protected:
CodeGenerator (BytecodeStream&);
};
BytecodeStream& _output;
CS 406: Design Patterns 33
Façade Pattern: Code [6]void ExpressionNode::Traverse (CodeGenerator& cg) {
cg.Visit (this);
ListIterator<Pnode*> i(_children);
For (i.First(); !i.IsDone(); i.Next();{
i.CurrentItem()Traverse(cg);
};
};
CS 406: Design Patterns 34
Façade Pattern: Code [7]class Compiler {
public:
// Façade. Offers a simple interface to compile and// Generate code.
Compiler();
}virtual void Compile (istream&, BytecodeStream&);
void Compiler:: Compile (istream& input, BytecodeStream& output) {
Scanner scanner (input);
PnodeBuilder builder;
Parser parser;
parser.Parse (scanner, builder);
RISCCodeGenerator generator (output);
Pnode* parseTree = builder.GetRootNode();parseTreeTraverse (generator);
}
Could also take a CodeGeneratorParameter for increased generality.
CS 406: Design Patterns 35
Facade Pattern: Another Example from POS [1]
– Only one item can be purchased using a gift certificate.
– Hence, subsequent enterItem operations must be invalidated in some cases. (Which ones?)
– Suppose that when a new Sale is created, it will be paid by a gift certificate
• Assume that rules are desired to invalidate an action:
How does a designer factor out the handling of such rules?
CS 406: Design Patterns 36
Facade Pattern: Another Example [2]
• Calls to this façade are placed near the start of the methods that need to be validated.
– Example: Invoke the façade to check if a new salesLineItem created by makeLineItem is valid or not. (See page 370 of Larman.)
• It evaluates a set of rules against an operation and indicates if the rule has invalidated an operation.
• Define a “rule engine” subsystem (e.g. POSRuleEngineFacade).
CS 406: Design Patterns 37
Toolkits and Frameworks
Toolkit
Main body of anApplication
Calls a procedure orA method
Framework
Reuse the main body of anApplication and write the code it calls
Defines the architectureOf the application
Toolkits: Collection of related and reusable classes e.g. C++ I/O stream library
Framework: A set of cooperating classes that make up a reusable design for a specific class of applications e.g. drawing, compilers, CAD/CAM etc.
CS 406: Design Patterns 38
Toolkits and Frameworks
Advantages and disadvantages of using frameworks.
2. What is more difficult to design: Application, toolkit, or frameworks?
3. How do changes in framework effect an application?
1. When using frameworks, what defines the architecture of the application?
4. How do design patterns differ from frameworks?
CS 406: Design Patterns 39
Abstract Factory: The Problem
1. Consider a user interface toolkit to support multiple look-and-feel standards.
2. For portability an application must not hard code its widgets for one look and feel.
How to design the application so that incorporating new look and feel requirements will be easy?
CS 406: Design Patterns 40
Abstract Factory Pattern: Solution[1]
2. This class declares an interface to create different kinds of widgets.
1. Define an abstract WidgetFactory class.
3. There is one abstract class for each kind of widget and concrete subclasses implement widgets for different
standards.
4. WidgetFactory offers an operation to return a new widget object for each abstract widget class. Clients call these operations to obtain instances of widgets without being aware of the concrete classes they use.
CS 406: Design Patterns 41
Abstract Factory: Solution[2]WidgetFactory
CreateScrollbar()
CreateWindow()
Window
ScrollBarWWidgetFactory
MacWidgetFactory
Client
WWindowMacWindow
MacScrollBar WScrollBar
One for each standard.
CS 406: Design Patterns 42
Abstract Factory: Solution[2]AbstractFactory
CreateScrollbar()
CreateWindow()
ConcreteFactory1
Client
ProductA1ProductA2
AbstractProductA
ProductB2 ProductB1
AbstractProductB
ConcreteFactory2
CreateProductA()
CreateProductB()
CS 406: Design Patterns 43
Abstract Factory Pattern: Participants and Communication
• ConcreteFactory: Implements the operations to create concrete product objects.
• AbstractProduct: Declares an interface for a type of product object.
• ConcreteProduct: Defines a product object to be created by the corresponding factory.
• AbstractFactory: Declares the interface for operations to create abstract product objects
• Client: Uses only the interface declared by the abstractFactory and AbstractProduct classes.
CS 406: Design Patterns 44
Abstract Factory Pattern: Code [1]class MazeFactory {
public:
MazeFactory();
virtual Maze* MakeMaze() const
{ return new Maze;}
// Creates components of mazes. // Builds rooms, walls, and doors.
virtual Wall* MakeWall() const
{ return new Wall;}
virtual Wall* MakeRoom(int n) const
{ return new Room;}
}// more methods.
// This factory is a collection of // factory methods. Also, this class// acts both as Abstract and Concrete // Factory
CS 406: Design Patterns 45
Abstract Factory Pattern: Code [1]Maze* MazeGame:: CreateMaze (MazeFactory& factory)
Maze* aMaze = factory.MakeMaze();
// Builds a maze.
}
Room* myroom = factory.MakeRoom(1);
Door* aDoor = factory.MakeDoor(myRoom,herRoom)
Room* herroom = factory.MakeRoom(2);
aMaze AddRoom(myRoom)
aMaze AddRoom(herRoom)
// More code to add walls.
// One can also create a// BombedMazeFactory with // different types of Rooms // and Walls.
CS 406: Design Patterns 46
Factory Method: The Problem [1]
1. Frameworks use abstract classes to define and maintain relationships between objects
2. Consider a framework for applications that present multiple documents to the user. A drawing application is an example.
3. This framework defines two abstract classes: application and document. These ought to be sub classed by clients for application specific implementation.
4. The application class will create and manage documents when required, e.g. when a New command is selected from the menu.
CS 406: Design Patterns 47
Factory Method Pattern: The Problem [2]
5. Document sub class is application specific. Hence the Application class does not know what kind of document to create!
6. Problem: The framework must instantiate classes but it only knows about the abstract classes, which it cannot initiate!
CS 406: Design Patterns 48
Factory Method Pattern: Solution[1]
2. Application subclasses redefine an abstract CreateDoc() method to return the appropriate Document subclass.
1. The Factory Method pattern encapsulates the knowledge of which Document subclass to create and moves this knowledge out of the framework.
3. When an Application is instantiated, it can instantiate application specific Documents without knowing their class.
CS 406: Design Patterns 49
Factory Method: Solution[2]
Document
Open()
Close()
Save()
Application
CreateDoc()NewDoc()OpenDoc()
MyApplication
CreateDoc()MyDocument
Document* doc=CreateDoc();docs.Add(doc);docOpen();
docs
1*
Factory method
CS 406: Design Patterns 50
Factory Method Pattern: Structure
Product Creator
FactoryMethod()SomeOperation()
ConcreteCreator
FactoryMethod()ConcreteProduct
product=Factory method
Return new ConcreteProduct
CS 406: Design Patterns 51
Factory Method Pattern: Participants and Communication
• ConcreteProduct (MyDocument): Implements the Product interface.
• Creator (Application): Declares factory method which returns an object of type Product. Also, may define the factory method to create a Product object.
• ConcreteCreator (MyApplication): Overrides the factory method to
return an instance of a ConcreteProduct.
• Product (Document): Defines the interface of objects the factory method creates.
CS 406: Design Patterns 52
Other Patterns: Singleton
• One may use a global variable to access an object but it does not prevent one from creating more than one instance.
• Instead the class itself is made responsible for keeping track of its instance. It can thus ensure that no more than one instance is created. This is the singleton pattern.
• Used to ensure that a class has only one instance. For example, one printer spooler object, one file system, one window manager, etc.
CS 406: Design Patterns 53
Singleton Structure
Singleton
static Instance()
SingletonOp()
GetSingletonData()
static uniqueInstance
singletonDatareturn uniqueinstance
CS 406: Design Patterns 54
Singleton Code [1]
class Singleton {
public:
static Singleton* Instance();
}
protected:
Singleton();
private:
Static Singleton* _instance
// Only one instance can ever be created.
// Creation hidden inside Instance().
// Cannot access directly.
CS 406: Design Patterns 55
Singleton Code [2]
Singleton* Singleton::_instance=0;
Singleton* Singleton:: Instance(){
if (_instance ==0) {_instance=new Singleton;
}Return _instance;
} // Clients access the singleton // exclusively via the Instance member // function.
56
Herzlichen Dank!