Visitor Design Pattern - Behavioral

1.1     Intent

Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates.

Separates the structure of an object from the operations that act on the structure.

1.2     Motivation

·         Consider a compiler that represents programs as abstract syntax trees. It will need to perform operations on abstract syntax trees for "static semantic" analyses like checking that all variables are defined. It will also need to generate code. It will be confusing to have type-checking code mixed with pretty-printing code or flow analysis code. It would be better if each new operation could be added separately, and the ode classes were independent of the operations that apply to them.

·         We can have both by packaging related operations from each class in a separate object, called a visitor, and passing it to elements of the abstract syntax tree as it's traversed. When an element accepts the visitor, it sends a request to the visitor that encodes the element's class. It also includes the element as an argument. The visitor will then execute the operation for that element—the operation that used to be in the class of the element.

·         Modular systems are easier to maintain.

·         Separation of functionality makes cleaner code.

1.3     Structure

1.4     Participants

 The classes and/or objects participating in this pattern are:

·         Visitor  (Visitor)

o   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. That lets the visitor determine the concrete class of the element being visited. Then the visitor can access the elements directly through its particular interface

·         ConcreteVisitor  (IncomeVisitor, VacationVisitor)

o   implements each operation declared by Visitor. Each operation implements a fragment of the algorithm defined for the corresponding class or object in the structure. ConcreteVisitor provides the context for the algorithm and stores its local state. This state often accumulates results during the traversal of the structure.

·         Element  (Element)

o   defines an Accept operation that takes a visitor as an argument.

·         ConcreteElement  (Employee)

o   implements an Accept operation that takes a visitor as an argument

·         ObjectStructure  (Employees)

o   can enumerate its elements

o   may provide a high-level interface to allow the visitor to visit its elements

o   may either be a Composite (pattern) or a collection such as a list or a set

 

1.5     Applicability

·         An object structure contains many classes of objects with differing interfaces…

·         Many distinct and unrelated operations need to be performed on objects in an object structure…

·         The classes defining the object structure rarely change, but you often want to define new operations over the structure…

1.6     Consequences

·         +flexibility: visitor & object structure are independent

·         +localized functionality

·         –circular dependency between Visitor & Element interfaces

·         –Visitor brittle to new ConcreteElementclasses

1.7     Sample Code

This structural code demonstrates the Visitor pattern in which an object traverses an object structure and performs the same operation on each node in this structure. Different visitor objects define different operations.

namespace Xpanxion.Visitor {     class MainApp     {         static void Main()         {             // Setup structure             ObjectStructure o = new ObjectStructure();             o.Attach(new ConcreteElementA());             o.Attach(new ConcreteElementB());             // Create visitor objects             ConcreteVisitor1 v1 = new ConcreteVisitor1();             ConcreteVisitor2 v2 = new ConcreteVisitor2();             // Structure accepting visitors             o.Accept(v1);             o.Accept(v2);             // Wait for user             Console.Read();         }     }     // "Visitor"     abstract class Visitor     {         public abstract void VisitConcreteElementA(           ConcreteElementA concreteElementA);         public abstract void VisitConcreteElementB(           ConcreteElementB concreteElementB);     }     // "ConcreteVisitor1"     class ConcreteVisitor1 : Visitor     {         public override void VisitConcreteElementA(           ConcreteElementA concreteElementA)         {             Console.WriteLine("{0} visited by {1}",               concreteElementA.GetType().Name, this.GetType().Name);         }         public override void VisitConcreteElementB(           ConcreteElementB concreteElementB)         {             Console.WriteLine("{0} visited by {1}",               concreteElementB.GetType().Name, this.GetType().Name);         }     }     // "ConcreteVisitor2"     class ConcreteVisitor2 : Visitor     {         public override void VisitConcreteElementA(           ConcreteElementA concreteElementA)         {             Console.WriteLine("{0} visited by {1}",               concreteElementA.GetType().Name, this.GetType().Name);         }         public override void VisitConcreteElementB(           ConcreteElementB concreteElementB)         {             Console.WriteLine("{0} visited by {1}",               concreteElementB.GetType().Name, this.GetType().Name);         }     }     // "Element"     abstract class Element     {         public abstract void Accept(Visitor visitor);     }     // "ConcreteElementA"     class ConcreteElementA : Element     {         public override void Accept(Visitor visitor)         {             visitor.VisitConcreteElementA(this);         }         public void OperationA()         {         }     }     // "ConcreteElementB"     class ConcreteElementB : Element     {         public override void Accept(Visitor visitor)         {             visitor.VisitConcreteElementB(this);         }         public void OperationB()         {         }     }     // "ObjectStructure"     class ObjectStructure     {         private ArrayList elements = new ArrayList();         public void Attach(Element element)         {             elements.Add(element);         }         public void Detach(Element element)         {             elements.Remove(element);         }         public void Accept(Visitor visitor)         {             foreach (Element e in elements)             {                 e.Accept(visitor);             }         }     } }

 

1.8     Sample Code2

This real-world code demonstrates the Visitor pattern in which two objects traverse a list of Employees and performs the same operation on each Employee. The two visitor objects define different operations -- one adjusts vacation days and the other income.

namespace DoFactory.GangOfFour.Visitor.RealWorld {     // MainApp startup application     class MainApp     {         static void Main()         {             // Setup employee collection             Employees e = new Employees();             e.Attach(new Clerk());             e.Attach(new Director());             e.Attach(new President());             // Employees are 'visited'             e.Accept(new IncomeVisitor());             e.Accept(new VacationVisitor());             // Wait for user             Console.Read();         }     }     // "Visitor"     interface IVisitor     {         void Visit(Element element);     }     // "ConcreteVisitor1"     class IncomeVisitor : IVisitor     {         public void Visit(Element element)         {             Employee employee = element as Employee;             // Provide 10% pay raise             employee.Income *= 1.10;             Console.WriteLine("{0} {1}'s new income: {2:C}",               employee.GetType().Name, employee.Name,               employee.Income);         }     }     // "ConcreteVisitor2"     class VacationVisitor : IVisitor     {         public void Visit(Element element)         {             Employee employee = element as Employee;             // Provide 3 extra vacation days             Console.WriteLine("{0} {1}'s new vacation days: {2}",               employee.GetType().Name, employee.Name,               employee.VacationDays);         }     }     class Clerk : Employee     {         // Constructor         public Clerk()             : base("Hank", 25000.0, 14)         {         }     }     class Director : Employee     {         // Constructor         public Director()             : base("Elly", 35000.0, 16)         {         }     }     class President : Employee     {         // Constructor         public President()             : base("Dick", 45000.0, 21)         {         }     }     // "Element"     abstract class Element     {         public abstract void Accept(IVisitor visitor);     }     // "ConcreteElement"     class Employee : Element     {         string name;         double income;         int vacationDays;         // Constructor         public Employee(string name, double income,           int vacationDays)         {             this.name = name;             this.income = income;             this.vacationDays = vacationDays;         }         // Properties         public string Name         {             get { return name; }             set { name = value; }         }         public double Income         {             get { return income; }             set { income = value; }         }         public int VacationDays         {             get { return vacationDays; }             set { vacationDays = value; }         }         public override void Accept(IVisitor visitor)         {             visitor.Visit(this);         }     }     // "ObjectStructure"     class Employees     {         private ArrayList employees = new ArrayList();         public void Attach(Employee employee)         {             employees.Add(employee);         }         public void Detach(Employee employee)         {             employees.Remove(employee);         }         public void Accept(IVisitor visitor)         {             foreach (Employee e in employees)             {                 e.Accept(visitor);             }             Console.WriteLine();         }     } }

 

1.9     C# Iterators and Visitor Pattern

The iterators are coded directly into the class to be iterated. For example:

public IEnumerable<int> Visit(SomeVisitor visitor)

{

int position = 0;

for(int i = 0; i < Count; i++)

{

yield return position;

data[i].Accept(visitor);

position++;

}

}

This can then be used in a foreach construct:

foreach(int position in someObject.Visit(this))

{

// Do something with position here.

}

Where 'someObject' is the object to traverse, the class of which contains the iterator code above, and 'this' is an instance of a class derived from 'SomeVisitor.'

So as the object is traversed, the iterator first returns the position information. Here it is just a simple integer, but it could be anything, something much more complex, perhaps. Then the Accept method is called.

The idea is that you can traverse a collection where the Visitor design pattern is used without having to explicitely call the Accept method; the iterator takes care of that for you. Plus, you get additional information about the traversal that can be used as well. Care would have to be taken so that you know which comes first, the value returned from the iterator or the Accept method being called.

Hope this helps.

Thanks & Regards,

Arun Manglick

Chain of Responsibility Design Pattern - Behavioural

1.1     Introduction

The classic CoR pattern defined by GoF in Design Patterns:

"Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it."

Figure illustrates the class diagram.

Typical object structure might look like Below Figure.

               

               

               

1.1     Intent

Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it.

1.2     Motivation

·         Consider a context-sensitive help system for a GUI

·         The object that ultimately provides the help isn't known explicitly to the object (e.g., a button) that initiates the help request

·         So use a chain of objects to decouple the senders from the receivers. The request gets passed along the chain until one of the objects handles it.

·         Each object on the chain shares a common interface for handling requests and for accessing its successor on the chain

1.3     Applicability

Use Chain of Responsibility:

·         When more than one object may handle a request and the actual handler is not know in advance

·         When requests follow a "handle or forward" model - that is, some requests can be handled where they are generated while others must be forwarded to another object to be handled

·         When a request has to be issued to several objects without specifying the receiver explicitly

·         The set of objects that can handle a request should be specified dynamically

1.4     Consequences

·         Reduced coupling between the sender of a request and the receiver – the sender and receiver have no explicit knowledge of each other

·         Receipt is not guaranteed - a request could fall off the end of the chain without being handled

·         The chain of handlers can be modified dynamically

·         Each C# object in the chain is self-contained. It knows nothing of the others and only need decide whether it can satisfy the request. This makes both writing each one and constructing the chain very easy.

·         You can decide whether the final object in the chain handles all requests it receives in some default fashion or just discards them. However, you do have to know which object will be last in the chain for this to be effective.

·         Finally, since C# cannot provide multiple inheritance, the basic Chain class sometimes needs to be an interface rather than an abstract class so the individual objects can inherit from another useful hierarchy, as we did here by deriving them all from Control. This disadvantage of this approach is that you often have to implement the linking, sending, and forwarding code in each module separately or, as we did here, by subclassing a concrete class that implements the Chain interface.

1.5     Structure

Class Diagram

Object Diagram

1.6     Example1

Scenario:

We are designing the software for a system that approves purchasing requests. The approval authority depends on the dollar amount of the purchase. The approval authority for a given dollar amount could change at any time and the system should be flexible enough to handle this situation.

Solution:

Use the Chain of Responsibility pattern. PurchaseRequest objects forward the approval request to a PurchaseApproval object. Depending on the dollar amount, the PurchaseApproval object may approve the request or forward it on to the next approving authority in the chain. The approval authority at any level in the chain can be easily modified without affecting the original PurchaseRequest object.

1.7     Example2

This code demonstrates the Chain of Responsibility pattern in which several linked objects (the Chain) are offered the opportunity to respond to a request or hand it off to the object next in line.

static void Main() {        // Setup Chain of Responsibility        Handler h1 = new ConcreteHandler1();        Handler h2 = new ConcreteHandler2();        Handler h3 = new ConcreteHandler3();        h1.SetSuccessor(h2);        h2.SetSuccessor(h3);        // Generate and process request        int[] requests = { 2, 5, 14, 22, 18, 3, 27, 20 };        foreach (int request in requests)        {               h1.HandleRequest(request);        }        // Wait for user        Console.Read(); }	abstract class Handler {        protected Handler successor;        public void SetSuccessor(Handler successor)        {               this.successor = successor;        }        public abstract void HandleRequest(int request); }
class ConcreteHandler1 : Handler     {         public override void HandleRequest(int request)         {             if (request >= 0 && request < 10)             {                 Console.WriteLine("{0} handled request {1}",                   this.GetType().Name, request);             }             else if (successor != null)             {                 successor.HandleRequest(request);             }         }     }	// "ConcreteHandler2"     class ConcreteHandler2 : Handler     {         public override void HandleRequest(int request)         {             if (request >= 10 && request < 20)             {                 Console.WriteLine("{0} handled request {1}",                   this.GetType().Name, request);             }             else if (successor != null)             {                 successor.HandleRequest(request);             }         }     }
// "ConcreteHandler3"     class ConcreteHandler3 : Handler     {         public override void HandleRequest(int request)         {             if (request >= 20 && request < 30)             {                 Console.WriteLine("{0} handled request {1}",                   this.GetType().Name, request);             }             else if (successor != null)             {                 successor.HandleRequest(request);             }         }     } }

1.8     Example3

This real-world code demonstrates the Chain of Responsibility pattern in which several linked managers and executives can respond to a purchase request or hand it off to a superior. Each position has can have its own set of rules which orders they can approve.

static void Main() {        // Setup Chain of Responsibility        Director Larry = new Director();        VicePresident Sam = new VicePresident();        President Tammy = new President();        Larry.SetSuccessor(Sam);        Sam.SetSuccessor(Tammy);        // Generate and process purchase requests        Purchase p = new Purchase(2034, 350.00, "Supplies");        Larry.ProcessRequest(p);        p = new Purchase(2035, 32590.10, "Project X");        Larry.ProcessRequest(p);        p = new Purchase(2036, 122100.00, "Project Y");        Larry.ProcessRequest(p);        // Wait for user        Console.Read(); }	abstract class Approver {   protected Approver successor;   public void SetSuccessor(Approver successor)   {    this.successor = successor;   }   public abstract void ProcessRequest(Purchase purchase); }
class Director : Approver {   public override void ProcessRequest(Purchase purchase)   {    if (purchase.Amount < 10000.0)    {        Console.WriteLine("{0} approved request# {1}",          this.GetType().Name, purchase.Number);    }    else if (successor != null)    {        successor.ProcessRequest(purchase);    }  } }	class VicePresident : Approver {    public override void ProcessRequest(Purchase purchase)    {       if (purchase.Amount < 25000.0)       {         Console.WriteLine("{0} approved request# {1}",             this.GetType().Name, purchase.Number);       }      else if (successor != null)       {         successor.ProcessRequest(purchase);       }     }  }
class President : Approver {  public override void ProcessRequest(Purchase purchase)  {   if (purchase.Amount < 100000.0)   {        Console.WriteLine("{0} approved request# {1}",          this.GetType().Name, purchase.Number);   }  else  {    Console.WriteLine("Request# {0} requires an                      executive meeting!",purchase.Number);  } } }

    // Request details

    class Purchase

    {

        private int number;

        private double amount;

        private string purpose;

        // Constructor

        public Purchase(int number, double amount, string purpose)

        {

            this.number = number;

            this.amount = amount;

            this.purpose = purpose;

        }

        // Properties

        public double Amount

        {

            get { return amount; }

            set { amount = value; }

        }

        public string Purpose

        {

            get { return purpose; }

            set { purpose = value; }

        }

        public int Number

        {

            get { return number; }

            set { number = value; }

        }

    }

}

1.9     Examples in C#

Under the covers, C# form windows receive various events, such as MouseMove, and then forward them to the controls the form contains. However, only the final control ever receives the message in C# whereas in some other languages, each containing control does as well. This is a clear implementation of Chain of Responsibility pattern.

We could also argue that, in general, the C# class inheritance structure itself exemplifies this pattern. If you call for a method to be executed in a deeply derived class, that method is passed up the inheritance chain until the first parent class containing that method is found. The fact that further parents contain other implementations of that method does not come into play.

We will also see that the Chain of Responsibility is ideal for implementing Interpreters and use one in the Interpreter pattern we discuss later.

Hope this helps.

Thanks & Regards,

Arun Manglick