Agile & Lean Software Development Management

The Visitor pattern uses an external class to act on data in other classes. This is a useful approach to you when you have a polymorphic operation that cannot reside in the class hierarchy. Visitor is also a useful way to extend the behavior of a class hierarchy without the need to alter existing classes or to implement the new behavior in every subclass that requires it.

I think the visitor pattern feels a bit of a weird pattern. I mean weird in a way that it feels not very object-oriented nor structured way of programming. On the other hand, sometimes you have a collection of similar classes which differ in one or more methods. If you don’t want to ‘pollute’ your object-oriented hierarchy with these class-specific methods, then you can use the visitor pattern.

All the client needs is an object structure, a visitor and an element. One or more elements are attached to the object structure. The visitor visits the object structure and does ‘something’ with the attached elements.

class Client
{
    static void Main()
    {
        ObjectStructure objectstructure = new ObjectStructure();
        Element element = new ConcreteElement();
        objectstructure.Attach(element);
        ConcreteVisitor visitor = new ConcreteVisitor();
        objectstructure.Accept(visitor);
        Console.ReadKey();

    }
}

The abstract class Visitor can have one or more concrete implementations, which do their work on the attached elements.

abstract class Visitor
{
    public abstract void VisitConcreteElement(ConcreteElement concreteElement);
}

class ConcreteVisitor : Visitor
{
    public override void VisitConcreteElement(ConcreteElement concreteElement)
    {
         Console.WriteLine("{0} visited by {1}", concreteElement.GetType().Name,          this.GetType().Name);
    }
}

The element class accepts a visitor and propagates an operation towards this visitor.

abstract class Element
{
    public abstract void Accept(Visitor visitor);
}

class ConcreteElement : Element
{
    public override void Accept(Visitor visitor)
    {
        visitor.VisitConcreteElement(this);
    }

    public void Operation()
    {
    }
}

The object structure contains all machinery needed for maintenance of a list of attached elements. In this way it resembles the subject class of the observer pattern.

class ObjectStructure
{
    private List m_Elements = new List();
    public void Attach(Element element)
    {
        m_Elements.Add(element);
    }
    public void Detach(Element element)
    {
        m_Elements.Remove(element);
    }
    public void Accept(Visitor visitor)
    {
        foreach (Element element in m_Elements)
        {
            element.Accept(visitor);
        }
    }
}

By now you should get some idea how the visitor pattern works.

Handy? I am not sure, I never used it in real life. What do you think. Please let me know.

This post is part of a series on the foundational design patterns in C#. In this series we explore the ancient design patterns and their use in real-world programming situations of today. In these series of posts we explore each pattern by looking at a minimalistic example to reveal its structure and then look at more concrete and useful real-world C# code that implements the pattern.

The Observer pattern is intended to provide you with a means to present data in several different forms at once so that when one object changes state, all its dependents are notified and updated automatically.

The Observer pattern can be found everywhere. Mostly it is used when you have more than one view on the same data. For example, a list view and a detail view.

In the client, a couple of observers are attached to their subject of interest. As soon as the state of the subject changes, all observers are notified that there is a change of state.

class Client
{
    static void Main()
    {
        ConcreteSubject subject = new ConcreteSubject();

        ConcreteObserver observer1 = new ConcreteObserver(subject, "A");
        subject.Attach(observer1);

        ConcreteObserver observer2 = new ConcreteObserver(subject, "B");
        subject.Attach(observer2);

        subject.SubjectState = "NEW_SUBJECT_STATE";
        subject.Notify();

        Console.ReadKey();
    }
}

The abstract parent class Subject contains a list of observers and methods necessary for attaching and detaching observers. Most important method is notify which traverses the list and notifies all attached observers.

abstract class Subject
{
    private List m_Observers = new List();
    public void Attach(Observer observer)
    {
        m_Observers.Add(observer);

    }
    public void Detach(Observer observer)
    {
        m_Observers.Remove(observer);

    }
    public void Notify()
    {
        foreach (Observer o in m_Observers)
        {
               o.Update();
         }
    }
}

The concrete child class contains a certain state, which can be virtually anything. In this example, something simple. Just a string containing im-por-tant information.

class ConcreteSubject : Subject
{
    public string SubjectState { get; set; }
}

All observers need some way to update their state when they are notified. This is done by implementing the Update method of abstract class Observer.

abstract class Observer
{
    public abstract void Update();
}

The concrete observer implements the abstract update method, plus its own methods.

class ConcreteObserver : Observer
{
    private string m_Name;
    private string m_ObserverState;

    public ConcreteObserver(ConcreteSubject subject, string name)
    {
        this.Subject = subject;
        this.m_Name = name;
    }

    public override void Update()
    {
        m_ObserverState = Subject.SubjectState;
        Console.WriteLine("Observer {0}'s new state is {1}", m_Name, m_ObserverState);
    }

    public ConcreteSubject Subject { get; set; }
}

When you think about the problem this pattern solves, you probably agree with me that this is a relatively simple but powerful pattern.

This post is part of a series on the foundational design patterns in C#. In this series we explore the ancient design patterns and their use in real-world programming situations of today. In these series of posts we explore each pattern by looking at a minimalistic example to reveal its structure and then look at more concrete and useful real-world C# code that implements the pattern.

The Mediator pattern is intended to define an object that encapsulates how a set of objects interacts. Object do not communicate directly with eachother, but through a mediator. This reduces the dependencies between communicating objects.

The client instantiates the communicating objects, so called colleagues, and a mediator through which they are communicating.

Colleague c1 = new ConcreteColleague1(m);
Colleague c2 = new ConcreteColleague2(m);

Mediator m = new ConcreteMediator();

m.AddColleague(c1);
m.AddColleague(c2);

c1.Send(c2, "Hello, c2. Are you there?");
c2.Send(c1, "No, goodbye!");

The abstract class Colleague contains a Mediator, which is injected at instantiation. In this example, it has two methods for communication. One for sending a message, the other for receiving a message.

abstract class Colleague
{
    protected Mediator mediator;

    public Colleague(Mediator mediator)
    {
        this.mediator = mediator;
    }

    abstract public void Send(Colleague to, string message);
    abstract public void Received(Colleague from, string message);
}

The abstract class Mediator contains an internal store for colleages and a method for adding colleagues. It also contains an abstract method for sending a message to the preferred colleague.

abstract class Mediator
{
    protected List colleagues = new List();

    public void AddColleague(Colleague colleague)
    {
        colleagues.Add(colleague);
    }

    public abstract void Send(Colleague colleague, string message);
}

The concrete class implements the abstract method. In this case, it forwards the message to the selected colleague.

class ConcreteMediator : Mediator
{
        public override void Send(Colleague to, string message)
        {
            to.Received(to,message);
        }
 }

Finally, the selected concrete colleague receives the message. I only show the concrete class ConcreteColleague1, since ConcreteColleague2 is almost identical to this one. So if you want to try this code, I suggest you do a search and replace on ConcreteColleague1.

class ConcreteColleague1 : Colleague
{
    public ConcreteColleague1(Mediator mediator)
    : base(mediator) { }

    override public void Send(Colleague to, string message)
    {
        Console.WriteLine("Sending message (ConcreteColleague1)-----------------------------");
        Console.WriteLine("To : " + to.GetType().Name);
        Console.WriteLine("Message: " + message);
        Console.WriteLine();

        mediator.Send(to,message);
    }

    override public void Received(Colleague from, string message)
    {
        Console.WriteLine("Receiving message (ConcreteColleague1)---------------------------");
        Console.WriteLine("From : " + from.GetType().Name);
        Console.WriteLine("Message: " + message);
        Console.WriteLine();
    }
}

This post is part of a series on the foundational design patterns in C#. In this series we explore the ancient design patterns and their use in real-world programming situations of today. In these series of posts we explore each pattern by looking at a minimalistic example to reveal its structure and then look at more concrete and useful real-world C# code that implements the pattern.

The iterator pattern provides a client with a way to access the elements of an aggregate object sequentially without having to know the underlying representation. The iterator is especially useful because it provides the client with a common interface so it doesn’t need to know anything about the underlying data structure.

If you want to loop through an collection of elements, the iterator pattern comes in very handy. In this example the client first fills an aggregate object with string elements. Next, an iterator is instantiated with the collection. Last, the iteration is done. The fun part is that you can change the implementations of underlying data and iterator without having to change the client.

Aggregate aggregate = new ConcreteAggregate();
for (int i = 0; i < 5; i++)
{
    aggregate[i] = string.Format("listitem {0}", i);
}
Iterator iterator = new ConcreteIterator(aggregate);
Console.WriteLine("Items in list:\n");
object item = iterator.First();
 while (item != null)
{
    Console.WriteLine(item);
    item = iterator.Next();
 }

The abstract aggregate class its most important abstract method is CreateIterator. For convenience of this example, an indexer and a property Count are also defined. The concrete aggregate object is just a wrapper around an ordinary ArrayList.

abstract class Aggregate
{
    public abstract object this[int i] { get; set; }
    public abstract int Count { get; }
    public abstract Iterator CreateIterator();
}

class ConcreteAggregate : Aggregate
{
    private ArrayList m_Items = new ArrayList();
    public override Iterator CreateIterator()
    {
        return new ConcreteIterator(this);

    }
    public override int Count
    {
        get
        {
            return m_Items.Count;

        }
    }
    public override object this[int index]
    {
        get
        {
            return m_Items[index];

        }
        set
        {
            m_Items.Insert(index, value);

        }
    }
}

The iterator does the looping work. First, an aggregate object is injected into the iterator upon instantiation. The rest of the code is just implementation of all abstract members.

class ConcreteIterator : Iterator
{
    private Aggregate m_Aggregate;
    private int m_Index = 0;

    public ConcreteIterator(Aggregate aggregate)
    {
        this.m_Aggregate = aggregate;
    }

    public override object First()
    {
        return m_Aggregate[0];
    }

    public override object Next()
    {
        object result = null;
        if (m_Index < m_Aggregate.Count - 1)
        {
            result = m_Aggregate[++m_Index];
        }
        return result;
    }

    public override object CurrentItem()
    {
        return m_Aggregate[m_Index];
    }

    public override bool IsDone()
    {
        return m_Index >= m_Aggregate.Count;
    }
}

Knowing this, can you imagine a real world situation when to use this pattern? This is such an important pattern, that it is a built-in pattern in C#. If you want read more about use of this pattern, read Using the Iterator Pattern in C# ASP .NET, by Kory Becker

This post is part of a series on the foundational design patterns in C#. In this series we explore the ancient design patterns and their use in real-world programming situations of today. In these series of posts we explore each pattern by looking at a minimalistic example to reveal its structure and then look at more concrete and useful real-world C# code that implements the pattern.

The Memento pattern provides you with the ability to restore an object to its previous state (undo by rollback).

The Memento pattern can have different purposes, but above all is known as the Undo Pattern. If you are mentally in an object oriented mood you could ask yourself…

Why on earth and above want they to put the internal data outside of the class in question? That’s not data hiding, is it?

… but the truth is that memento pattern doesn’t violate encapsulation of the internal state.

As a consequence, this pattern can come very handy when you want to store its internal state and reclaim it later without knowledge of the original object.

The client creates an originator object, which has a certain internal state. This can be any object, of course. The important objects are the caretaker and memento. A memento is created by the originator and stored in the caretaker. At a later point in time the previous state can be restored by setting the originators memento to the caretaker’s stored memento.

class Client
{
    public static void Run()
    {
        Originator originator = new Originator();
        originator.State = "First state";
        // a memento is created and stored
        Caretaker caretaker = new Caretaker();
        caretaker.Memento = originator.CreateMemento();
        // change the internal state of the originator object
        originator.State = "Second state";
        Console.WriteLine("Restoring previous state.");
        originator.SetMemento(caretaker.Memento);

    }
}

The originator object can be any object, as long as they implement a CreateMemento and SetMemento method. The CreateMemento method should return a filled memento object, whilst the SetMemento should read the data stored in the memento and restore its internal state.

class Originator
{
    private string m_State;
    public string State
    {
        get { return m_State; }
        set
        {
            m_State = value;
            Console.WriteLine("current state = {0}", m_State);
        }
    }

    public Memento CreateMemento()
    {
        return (new Memento(State));
    }

    public void SetMemento(Memento memento)
    {
        State = memento.State;
    }
}

The Memento object contains the originators internal state, so must have a similar structure. To design a Memento class you could start with a copy of the originator class and strip all unnecessary methods and attributes.

class Memento
{
    private string m_State;
    public Memento(string state)
    {
        this.m_State = state;
    }

    public string State
    {
        get { return m_State; }
    }
}

The Caretaker only contains the memento. In this example there is just one memento, but normally the caretaker contains a list of mementos.

class Caretaker
{
    public Memento Memento;

}

And of course, you can click here for a simplified real world example.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

enum ArticleStatus
{
    Draft,
    PendingReview,
    Published
}

class Client
{
    static void Run(string[] args)
    {
        // initial state
        Article article = new Article();
        article.Status = ArticleStatus.Draft;

        // save state
        StatusStore store = new StatusStore();
        store.StoredStatus = article.CreateStoredStatus();

        // user pressed the publish button
        article.Status = ArticleStatus.Published;
        article.Save();

        // user presse the undo button
        article.RestoreToPreviousState(store.StoredStatus);
        article.Save();
    }
}

class Article
{
    private ArticleStatus m_State;
    public ArticleStatus Status
    {
        get { return m_State; }
        set
        {
            m_State = value;
        }
    }
    public void Save()
    {
        // persisting logic
    }
    public ArticleState CreateStoredStatus()
    {
        return (new ArticleState(Status));
    }

    public void RestoreToPreviousState(ArticleState memento)
    {
        Status = memento.State;
    }
}

class ArticleState
{
    private ArticleStatus m_State;
    public ArticleState(ArticleStatus state)
    {
        this.m_State = state;
    }

    public ArticleStatus State
    {
        get { return m_State; }
    }
}

class StatusStore
{
    public ArticleState StoredStatus;
}

This post is part of my series on the foundational design patterns in C#. In this series I explore the ancient design patterns and their use in real-world programming situations of today. In these series of posts we explore each pattern by looking at a minimalistic example to reveal its structure and then look at more concrete and useful real-world C# code that implements the pattern.