Design Patterns II 1. Behavioral Pattern Visitor: intent and structure Represent an operation to be performed on the elements of an object structure.

Slides:



Advertisements
Similar presentations
Chain of Responsibility Pattern Gof pp Yuyang Chen.
Advertisements

The Observer Pattern SE-2811 Dr. Mark L. Hornick 1.
Observer Method 1. References Gamma Erich, Helm Richard, “Design Patterns: Elements of Reusable Object- Oriented Software” 2.
1 Structural Design Patterns - Neeraj Ray. 2 Structural Patterns - Overview n Adapter n Bridge n Composite n Decorator.
02 - Structural Design Patterns – 1 Moshe Fresko Bar-Ilan University תשס"ח 2008.
Design Patterns Section 7.1 (JIA’s) Section (till page 259) (JIA’s) Section 7.2.2(JIA’s) Section (JIA’s)
Matt Klein 7/2/2009.  Intent  Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request.
Observer Pattern Fall 2005 OOPD John Anthony. What is a Pattern? “Each pattern describes a problem which occurs over and over again in our environment,
Zaki Alasadi Supervisor:Dr noorhosseini.
1 Pattern Games CS : Software Design Winter /T9.
Design Patterns In OPM Presented by: Galia Shlezinger Instructors: Prop. Dov Dori, Dr. Iris Berger.
Software Design & Documentation – Design Pattern: Command Design Pattern: Command Christopher Lacey September 15, 2003.
BehavioralCmpE196G1 Behavioral Patterns Chain of Responsibility (requests through a chain of candidates) Command (encapsulates a request) Interpreter (grammar.
Command Pattern Chihung Liao Cynthia Jiang. Waiter Order Execute() Hamburger Execute() Hot Dogs Execute() Fries Execute() Cook Make Food()
March Ron McFadyen1 Adapter An adapter converts the interface of a class into another interface clients expect. An adapter lets classes work.
Algorithm Programming Behavioral Design Patterns Bar-Ilan University תשס " ו by Moshe Fresko.
ECE450 - Software Engineering II1 ECE450 – Software Engineering II Today: Design Patterns VI Composite, Iterator, and Visitor Patterns.
Behavioral Patterns C h a p t e r 5 – P a g e 128 BehavioralPatterns Design patterns that identify and realize common interactions between objects Chain.
Behavioral Patterns  Behavioral patterns are patterns whose purpose is to facilitate the work of algorithmic calculations and communication between classes.
BDP Behavioral Pattern. BDP-2 Behavioral Patters Concerned with algorithms & assignment of responsibilities Patterns of Communication between Objects.
Design Patterns.
Department of Computer Science, York University Object Oriented Software Construction 16/09/ :52 PM 0 COSC3311 – Software Design Decorator Pattern.
02 - Behavioral Design Patterns – 2 Moshe Fresko Bar-Ilan University תשס"ח 2008.
CS 210 Introduction to Design Patterns September 28 th, 2006.
Design Patterns Lecture III. What Is A Pattern? Current use comes from the work of the architect Christopher Alexander Alexander studied ways to improve.
Design Pattern. The Observer Pattern The Observer Pattern defines a one-to-many dependency between objects so that when one object changes state, all.
Observer Behavioral Pattern. Intent Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified.
ECE450 - Software Engineering II1 ECE450 – Software Engineering II Today: Design Patterns VII Observer, Command, and Memento.
Design Patterns CSCI 5801: Software Engineering. Design Patterns.
Lexi case study (Part 2) Presentation by Matt Deckard.
Decorator Explained. Intent Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to sub-classing for.
Linzhang Wang Dept. of Computer Sci&Tech, Nanjing University The Command Pattern.
Design Patterns CSIS 3701: Advanced Object Oriented Programming.
ECE450 - Software Engineering II1 ECE450 – Software Engineering II Today: Design Patterns IV Structural Patterns.
ECE450 - Software Engineering II1 ECE450 – Software Engineering II Today: Design Patterns VIII Chain of Responsibility, Strategy, State.
Proxy, Observer, Symbolic Links Rebecca Chernoff.
Behavioural Design Patterns Quote du jour: ECE450S – Software Engineering II I have not failed. I've just found 10,000 ways that won't work. - Thomas Edison.
OBSERVER DESIGN PATTERN. Behavioral Patterns  Behavioral patterns are those patterns that are most specifically concerned with communication between.
Manali Joshi1 The Observer Design Pattern Presented By: Manali Joshi.
CS 210 Final Review November 28, CS 210 Adapter Pattern.
Behavioral Patterns1 Nour El Kadri SEG 3202 Software Design and Architecture Notes based on U of T Design Patterns class.
Chain of Responsibility Behavioral Pattern. Defination Avoid coupling between the sender and receiver by giving more than one object a chance to handle.
BEHAVIORAL PATTERNS 13-Sep-2012 Presenters Sanjeeb Kumar Nanda & Shankar Gogada.
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 31. Review Creational Design Patterns – Singleton Pattern – Builder Pattern.
The Visitor Pattern (Behavioral) ©SoftMoore ConsultingSlide 1.
Bridge Bridge is used when we need to decouple an abstraction from its implementation so that the two can vary independently. This type of design pattern.
Example to motivate discussion We have two lists (of menu items) one implemented using ArrayList and another using Arrays. How does one work with these.
S.Ducasse Stéphane Ducasse 1 Decorator.
The Decorator Pattern (Structural) ©SoftMoore ConsultingSlide 1.
CS 210 Proxy Pattern Nov 16 th, RMI – A quick review A simple, easy to understand tutorial is located here:
CSE 332: Design Patterns (Part II) Last Time: Part I, Familiar Design Patterns We’ve looked at patterns related to course material –Singleton: share a.
The Chain of Responsibility Pattern (Behavioral) ©SoftMoore ConsultingSlide 1.
S.Ducasse Stéphane Ducasse 1 Adapter.
OBSERVER PATTERN OBSERVER PATTERN Presented By Presented By Ajeet Tripathi ISE
Command Pattern. Intent encapsulate a request as an object  can parameterize clients with different requests, queue or log requests, support undoable.
Structural Patterns Structural patterns control the relationships between large portions of your applications. Structural patterns affect applications.
Linzhang Wang Dept. of Computer Sci&Tech, Nanjing University
Behavioral Design Patterns
Observer Design Pattern
Design Patterns with C# (and Food!)
Design Patterns - A few examples
Decorator Pattern Intent
Informatics 122 Software Design II
Behavioral Patterns Part-I introduction UNIT-VI
Behavioral Design Pattern
PH Chapter 3 Thanks for the Memory Leaks Pushme-Pullyu (pp
Structural Patterns: Adapter and Bridge
Informatics 122 Software Design II
Decorator Pattern.
Software Design Lecture 11.
Presentation transcript:

Design Patterns II 1

Behavioral Pattern Visitor: intent and structure Represent an operation to be performed on the elements of an object structure. 2

Visitor: structure 3

Visitor: participants Visitor (IChef)  declares a Visit operation for each class of ConcreteElement in the object structure. The operation's name and signature identifies the class that sends the Visit request to the visitor. ConcreteVisitor (ChefWong, ChefZung)  implements each operation declared by Visitor. Element (AEater)  defines an Accept operation that takes a visitor as an argument. ConcreteElement (Vegetarian, Carnivore )  implements an Accept operation that takes a visitor as an argument. ObjectStructure  may provide a high-level interface to allow the visitor to visit its elements 4

Visitor: collaborations 5

Visitor: implementation /* Visitor */ interface IChef { String cookVeggie(Vegetarian h, Integer n); String cookMeat(Carnivore h, Integer n); } /* Concrete Visitor 1 */ class ChefWong implements IChef { public String cookVeggie(Vegetarian h, Integer n) { return n + ":" + h.getBroccoli() + ", " + h.getSalt(); } public String cookMeat(Carnivore h, Integer n) { return n + ":" + h.getMeat() + ", " + h.getPepper(); } } /* Concrete Visitor 2 */ class ChefZung implements IChef { public String cookVeggie(Vegetarian h, Integer n) { return n + ":" + h.getCorn() + ", " + h.getSalt(); } public String cookMeat(Carnivore h, Integer n) { return n + ":" + h.getChicken() + ", " + h.getPepper(); } } /* Visitor */ interface IChef { String cookVeggie(Vegetarian h, Integer n); String cookMeat(Carnivore h, Integer n); } /* Concrete Visitor 1 */ class ChefWong implements IChef { public String cookVeggie(Vegetarian h, Integer n) { return n + ":" + h.getBroccoli() + ", " + h.getSalt(); } public String cookMeat(Carnivore h, Integer n) { return n + ":" + h.getMeat() + ", " + h.getPepper(); } } /* Concrete Visitor 2 */ class ChefZung implements IChef { public String cookVeggie(Vegetarian h, Integer n) { return n + ":" + h.getCorn() + ", " + h.getSalt(); } public String cookMeat(Carnivore h, Integer n) { return n + ":" + h.getChicken() + ", " + h.getPepper(); } } 6

Visitor: implementation (cont.) /* Element */ abstract class AEater { String getSalt() { return "salt"; } String getPepper() { return "pepper"; } abstract String order(IChef c, Integer n); } /* Concrete Element 1 */ class Vegetarian extends AEater { String getBroccoli() { return "broccoli"; } String getCorn() { return "corn"; } String order(IChef c, Integer n) { return c.cookVeggie(this, n); } } /* Concrete Element 2 */ class Carnivore extends AEater { String getMeat() { return "steak"; } String getChicken() { return "cornish hen"; } String order(IChef c, Integer n) { return c.cookMeat(this, n); } } /* Client */ AEater John = new Carnivore(); AEater Mary = new Vegetarian(); Mary.order(new ChefWong(), 2); John.order(new ChefZung(), 3); /* Element */ abstract class AEater { String getSalt() { return "salt"; } String getPepper() { return "pepper"; } abstract String order(IChef c, Integer n); } /* Concrete Element 1 */ class Vegetarian extends AEater { String getBroccoli() { return "broccoli"; } String getCorn() { return "corn"; } String order(IChef c, Integer n) { return c.cookVeggie(this, n); } } /* Concrete Element 2 */ class Carnivore extends AEater { String getMeat() { return "steak"; } String getChicken() { return "cornish hen"; } String order(IChef c, Integer n) { return c.cookMeat(this, n); } } /* Client */ AEater John = new Carnivore(); AEater Mary = new Vegetarian(); Mary.order(new ChefWong(), 2); John.order(new ChefZung(), 3); 7

Visitor: consequences Consequences: Visitor lets you define a new operation without changing the classes of the elements on which it operates. A visitor gathers related operations and separates unrelated ones. Adding new ConcreteElement classes is hard. Visiting across class hierarchies. Accumulating state. Breaking encapsulation. 8

Structural Pattern Decorator: intent and structure Decorators provide a flexible alternative to subclassing for extending functionality. 9

Decorator: participants Component (Window)  defines the interface for objects that can have responsibilities added to them dynamically. ConcreteComponent (SimpleWindow)  defines an object to which additional responsibilities can be attached. Decorator (WindowDecorator)  maintains a reference to a Component object and defines an interface that conforms to Component's interface. ConcreteDecorator (ScrollBarDecorator, BorderDecorator)  adds responsibilities to the component. 10

Decorator: implementation /* Component */ public interface Window { public void draw(); } /* Concrete Component */ public class SimpleWindow implements Window { public void draw() {…} public String toString() { return "Simple window"; } } /* Decorator */ abstract class WindowDecorator implements Window { protected Window w; public WindowDecorator (Window w) { this.w = w; } } /* Concrete Decorator 1 */ class ScrollBarDecorator extends WindowDecorator { public ScrollBarDecorator(Window w) { super(w); } public void draw() { drawScrollBar(); w.draw(); } private void drawScrollBar() {…} public String toString() { return w + " including scroll bar"; } } /* Component */ public interface Window { public void draw(); } /* Concrete Component */ public class SimpleWindow implements Window { public void draw() {…} public String toString() { return "Simple window"; } } /* Decorator */ abstract class WindowDecorator implements Window { protected Window w; public WindowDecorator (Window w) { this.w = w; } } /* Concrete Decorator 1 */ class ScrollBarDecorator extends WindowDecorator { public ScrollBarDecorator(Window w) { super(w); } public void draw() { drawScrollBar(); w.draw(); } private void drawScrollBar() {…} public String toString() { return w + " including scroll bar"; } } 11

Decorator: implementation (cont.) /* Concrete Decorator 2 */ public class BorderDecorator extends WindowDecorator { public BorderDecorator(Window w) { super(w); } public void draw() { drawBorder(); w.draw(); } private void drawBorder() {…} public String getDescription(){ return w + " including border"; } } /* Client */ public class Client { public void run() { Window decoratedWindow = new ScrollBarDecorator( new BorderDecorator( new SimpleWindow())); System.out.println(decoratedWindow); } /* Concrete Decorator 2 */ public class BorderDecorator extends WindowDecorator { public BorderDecorator(Window w) { super(w); } public void draw() { drawBorder(); w.draw(); } private void drawBorder() {…} public String getDescription(){ return w + " including border"; } } /* Client */ public class Client { public void run() { Window decoratedWindow = new ScrollBarDecorator( new BorderDecorator( new SimpleWindow())); System.out.println(decoratedWindow); } 12

Decorator: consequences Consequences: More flexibility than static inheritance. Avoids feature-laden classes high up in the hierarchy. A decorator and its component aren't identical. Lots of little objects. 13

Structural Pattern Adapter: intent and structure Convert the interface of a class into another interface clients expect. 14

Adapter: participants Target (Stack)  defines the domain-specific interface that Client uses. Client  collaborates with objects conforming to the Target interface. Adaptee (DList)  defines an existing interface that needs adapting. Adapter (DListImpStack)  adapts the interface of Adaptee to the Target interface. 15

Class Adapter: implementation /* Target */ interface Stack { void push (T o); T pop (); T top (); } /* Adaptee */ public class DList { public void insertHead (T o) {…} public void insertTail (T o) {…} public T removeHead () {…} public T removeTail () {…} public T getHead () {…} public T getTail () {…} } /* Adapter */ public class DListImpStack extends DList implements Stack { public void push (T o) { insertTail (o); } public T pop () { return removeTail (); } public T top () { return getTail (); } } /* Target */ interface Stack { void push (T o); T pop (); T top (); } /* Adaptee */ public class DList { public void insertHead (T o) {…} public void insertTail (T o) {…} public T removeHead () {…} public T removeTail () {…} public T getHead () {…} public T getTail () {…} } /* Adapter */ public class DListImpStack extends DList implements Stack { public void push (T o) { insertTail (o); } public T pop () { return removeTail (); } public T top () { return getTail (); } } 16

Adapter: consequences Consequences: A class adapter a class adapter won't work when we want to adapt a class and all its subclasses. lets Adapter override some of Adaptee's behavior no additional pointer indirection is needed to get to the adaptee. An object adapter lets a single Adapter work with many Adaptees makes it harder to override Adaptee behavior. 17

Behavioral Pattern Command: intent and structure Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations. 18

Command: participants Command (Command)  declares an interface for executing an operation. ConcreteCommand (MoveUpCommand, MoveRightCommand)  defines a binding between a Receiver object and an action.  implements Execute by invoking the corresponding operation(s) on Receiver. Client (Game)  creates a ConcreteCommand object and sets its receiver. Invoker (Game)  asks the command to carry out the request. Receiver (GameBoard)  knows how to perform the operations associated with carrying out a request. Any class may serve as a Receiver. 19

Command: implementation /* Receiver */ public class GameBoard { public int x = 0; public int y = 0; public static final int XMAX = 10; public static final int YMAX = 10; public void incX() { if (x < GameBoard.XMAX) ++x; } public void decX() { if (x > 0) --x; } public void incY() { if (y < GameBoard.YMAX) ++y; } public void decY() { if (y > 0) --y; } } /* Command */ public interface Command { void execute(); void undo(); } /* Concrete Command 1 */ public class MoveUpCommand implements Command { private GameBoard gb; public MoveUpCommand(GameBoard gb) { this.gb = gb; } public void execute() { gb.incY(); } public void undo() { gb.decY(); } } /* Receiver */ public class GameBoard { public int x = 0; public int y = 0; public static final int XMAX = 10; public static final int YMAX = 10; public void incX() { if (x < GameBoard.XMAX) ++x; } public void decX() { if (x > 0) --x; } public void incY() { if (y < GameBoard.YMAX) ++y; } public void decY() { if (y > 0) --y; } } /* Command */ public interface Command { void execute(); void undo(); } /* Concrete Command 1 */ public class MoveUpCommand implements Command { private GameBoard gb; public MoveUpCommand(GameBoard gb) { this.gb = gb; } public void execute() { gb.incY(); } public void undo() { gb.decY(); } } 20

Command: implementation (cont.) /* Concrete Command 2 */ public class MoveRightCommand implements Command { private GameBoard gb; public MoveRightCommand (GameBoard gb) { this.gb = gb; } public void execute() { gb.incX(); } public void undo() { gb.decX();} } /* Invoker */ public class Game { private GameBoard gb = new GameBoard(); private Command moveUpCommand; private Command moveLeftCommand; public Game() { moveUpCommand = new MoveUpCommand(gb); moveLeftCommand = new MoveRightCommand(gb); } public void action() { moveUpCommand.execute(); moveLeftCommand.execute(); } /* Concrete Command 2 */ public class MoveRightCommand implements Command { private GameBoard gb; public MoveRightCommand (GameBoard gb) { this.gb = gb; } public void execute() { gb.incX(); } public void undo() { gb.decX();} } /* Invoker */ public class Game { private GameBoard gb = new GameBoard(); private Command moveUpCommand; private Command moveLeftCommand; public Game() { moveUpCommand = new MoveUpCommand(gb); moveLeftCommand = new MoveRightCommand(gb); } public void action() { moveUpCommand.execute(); moveLeftCommand.execute(); } 21

Command: consequences Consequences: Command decouples the object that invokes the operation from the one that knows how to perform it. Commands are first-class objects. They can be manipulated and extended like any other object. You can assemble commands into a composite command. It's easy to add new Commands, because you don't have to change existing classes. 22

Behavioral Pattern Observer: intent and structure Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. 23

Observer: participants Subject  knows its observers. Any number of Observer objects may observe a subject.  provides an interface for attaching and detaching Observer objects. ConcreteSubject (PowerVector)  stores state of interest to ConcreteObserver objects.  sends a notification to its observers when its state changes. Observer (IObserver)  defines an updating interface for objects that should be notified of changes in a subject. ConcreteObserver (SizeKeeper)  maintains a reference to a ConcreteSubject object.  stores state that should stay consistent with the subject's.  implements the Observer updating interface to keep its state consistent with the subject's. 24

Observer: implementation /* Concrete Subject */ public class PowerVector { private ArrayList items = new ArrayList (); private ArrayList observers = new ArrayList (); public int size() { return items.size(); } public void addObserver(IObserver ob) { observers.add(ob); } public void add(Object o) { items.add(o); notifyObservers(); } public void remove(Object o) { items.remove(o); notifyObservers(); } public void notifyObservers() { for (IObserver ob: observers) ob.update(this); } /* Concrete Subject */ public class PowerVector { private ArrayList items = new ArrayList (); private ArrayList observers = new ArrayList (); public int size() { return items.size(); } public void addObserver(IObserver ob) { observers.add(ob); } public void add(Object o) { items.add(o); notifyObservers(); } public void remove(Object o) { items.remove(o); notifyObservers(); } public void notifyObservers() { for (IObserver ob: observers) ob.update(this); } 25

Observer: implementation (cont.) /* Observer */ public interface IObserver { public void update(PowerVector subject); } /* Concrete Observer */ public class SizeKeeper implements IObserver { private int size; public void update(PowerVector subject) { size = subject.size(); } public int size() { return size; } } /* Client */ public class Client { private PowerVector v = new PowerVector(); public void run(){ v.addObserver(new SizeKeeper()); v.add(1); v.add(2); System.out.println(v.size()); } /* Observer */ public interface IObserver { public void update(PowerVector subject); } /* Concrete Observer */ public class SizeKeeper implements IObserver { private int size; public void update(PowerVector subject) { size = subject.size(); } public int size() { return size; } } /* Client */ public class Client { private PowerVector v = new PowerVector(); public void run(){ v.addObserver(new SizeKeeper()); v.add(1); v.add(2); System.out.println(v.size()); } 26

Observer: consequences Consequences: Abstract coupling between Subject and Observer. Support for broadcast communication. Unexpected updates. 27

Behavioral Pattern Chain-of-Responsibility: intent and structure Chain the receiving objects and pass the request along the chain until an object handles it. 28

Chain-of-Responsibility: participants Handler (Filter)  defines an interface for handling requests.  (optional) implements the successor link. ConcreteHandler (EvenFilter, PrimeFilter)  handles requests it is responsible for.  can access its successor.  if the ConcreteHandler can handle the request, it does so; otherwise it forwards the request to its successor. Client (Client)  initiates the request to a ConcreteHandler object on the chain. 29

Chain-of-Responsibility: implementation /* Handler */ public class Filter { private Filter next = null; public void attach(Filter other) { other.next = this.next; this.next = other; } public final void invoke(int v) { if (this.handle(v)) return; if (next != null) next.invoke(v); } public boolean handle(int v) { return false;} } /* Concrete Handler 1 */ public class EvenFilter extends Filter { public boolean handle(int v) { return (v % 2 == 0);} } /* Concrete Handler 2 */ public class PrimeFilter extends Filter { public boolean handle(int v) { for (int i = 2; i * i <= v; ++i) if (v % i == 0) return false; return true; } /* Handler */ public class Filter { private Filter next = null; public void attach(Filter other) { other.next = this.next; this.next = other; } public final void invoke(int v) { if (this.handle(v)) return; if (next != null) next.invoke(v); } public boolean handle(int v) { return false;} } /* Concrete Handler 1 */ public class EvenFilter extends Filter { public boolean handle(int v) { return (v % 2 == 0);} } /* Concrete Handler 2 */ public class PrimeFilter extends Filter { public boolean handle(int v) { for (int i = 2; i * i <= v; ++i) if (v % i == 0) return false; return true; } 30

Chain-of-Responsibility: implementation (cont.) /* Client */ public class Client { private ArrayList l = new ArrayList (); private Filter chain = new Filter(); public Client() { chain.attach(new Filter() { public boolean handle(int v) { l.add(v); return true; } }); chain.attach(new EvenFilter()); chain.attach(new PrimeFilter()); } public void run() { for (int i = 0; i < 10; ++i) chain.invoke(i); System.out.println("Size = " + l.size()); } /* Client */ public class Client { private ArrayList l = new ArrayList (); private Filter chain = new Filter(); public Client() { chain.attach(new Filter() { public boolean handle(int v) { l.add(v); return true; } }); chain.attach(new EvenFilter()); chain.attach(new PrimeFilter()); } public void run() { for (int i = 0; i < 10; ++i) chain.invoke(i); System.out.println("Size = " + l.size()); } 31

Chain-of-Responsibility: consequences Consequences: Reduced coupling. Added flexibility in assigning responsibilities to objects. Receipt isn't guaranteed. 32