Design Patterns Archives - Michał Kajzer

Design Patterns #10: State

Design patterns episode 10 – State

Happy Christmas!! Isn’t it a good time to write a post?
Let me start with an apology. In previous post about patterns (composite) I promised to keep that one week/one pattern schedule but as you can see I have failed. But in the meantime I posted something different (one-bytes #1) so I feel forgiven to some extent. Learnt by experience I promise nothing this time. With that being said we can proceed to the next pattern.

Today’s hero is the State. We all know those simple machines which operation model is frequently very simple but closed within exact patterns. For instance the example given in Head First book – a vending machine. It allows only two or three possible interactions (insert coin, get coin back or get the product) and serves one particular purpose (sell products). Its operation model is base on states: the machine can have a coin inserted, can be out of products, etc. So the machine changes its internal state and this change implicates change of behaviour.

DEFINITION
Let’s take a look at the definition and the diagram.

The State Pattern allows an object to alter its behavior when its internal state changes. The object will appear to change its class.
(Freeman, Eric, et al. Head First Design Patterns. O’Reilly Media, Inc. 2004)

In object-oriented programming the above definition is realised by representing these internal states by different implementations of one interface (or inherited from an abstract class). The important thing is the fact the state changes internally. It is not possible to set state from outside. If we go back and think about strategy pattern we will probably see that these two pattern are similar but that closure to changes from outside is what makes them different.

This the diagram depicting the state pattern and similarly to strategy pattern we have encapsulation of behaviour in a separate class: behaviour of Operation() method in context class is encapsulated in state object. It is possible to have multiple states but transitions between them must be done privately. User of state context must not be able to enforce the context to switch state in any other means than normal operation on the context, intended by designer. We don’t have any public method to set the current state from outside. And that is the key to state pattern.

EXAMPLE
I have used a prepaid electricity meter to show the pattern. It can be thought of as a state machine: it can be switch off, switched on but idle, conducting electricity to appliances or be out of credits. Let’s start with the meter interface:

public interface IMeter
{
    uint Credit { get; }
    AMeterState CurrentState { get; }

    void PowerOn();
    void PowerOff();
    void Start(uint _time);
    void TopUp(uint _value);
}

public interface IMeter

{

uint Credit { get; }

AMeterState CurrentState { get; }

void PowerOn();

void PowerOff();

void Start(uint _time);

void TopUp(uint _value);

}

It exposes two properties: one is the credit that the meter is topped-up with, the other is current state of the meter. Both of them are get-only: there is specific method to top-up and the state cannot be set from the outside. Other than that we have methods to turn the meter on/off, start delivering power (for specified number of cycles) and already mentioned TopUp() method.

public class Meter : IMeter
{
    public uint Credit { get; private set; }
    public AMeterState CurrentState { get; set; }

    public AMeterState OffState { get; private set; }
    public AMeterState OnState { get; private set; }
    public AMeterState MinusState { get; private set; }

    public uint AddCredit(uint _value)
    {
        Credit += _value;
        return Credit;
    }

    public void TakeCredit()
    {
        Credit--;
    }

    public Meter()
    {
        OffState = new OffState(this);
        OnState = new OnState(this);
        MinusState = new MinusState(this);
        Credit = 0;
        CurrentState = OffState;
    }

    public void PowerOn()
    {
        CurrentState.PowerOn();
    }

    public void PowerOff()
    {
        CurrentState.PowerOff();
    }

    public void Start(uint _time)
    {
        CurrentState.Start(_time);
    }

    public void TopUp(uint _value)
    {
        CurrentState.TopUp(_value);
    }
}

public class Meter : IMeter

{

public uint Credit { get; private set; }

public AMeterState CurrentState { get; set; }

public AMeterState OffState { get; private set; }

public AMeterState OnState { get; private set; }

public AMeterState MinusState { get; private set; }

public uint AddCredit(uint _value)

{

Credit += _value;

return Credit;

}

public void TakeCredit()

{

Credit--;

}

public Meter()

{

OffState = new OffState(this);

OnState = new OnState(this);

MinusState = new MinusState(this);

Credit = 0;

CurrentState = OffState;

}

public void PowerOn()

{

CurrentState.PowerOn();

}

public void PowerOff()

{

CurrentState.PowerOff();

}

public void Start(uint _time)

{

CurrentState.Start(_time);

}

public void TopUp(uint _value)

{

CurrentState.TopUp(_value);

}

The implementation of the meter is slightly more complicated. First we need to equip properties from the interface with setters. Next we need properties for each of the possible states. In this case there are three states: OnState, OffState and MinusState. Other than that we have methods to manipulate with credit and a constructor. This is important: we initialise state instances, set credit to zero and set current state to OffState. The last step is four methods from the IMeter interface. These methods don’t have their own implementation but they call current state object to execute its corresponding operations.
Now the abstraction of state class. In this case I’m using abstract class because I need some not public members, force the inheriting classes to set reference in constructor to the meter the state is going to be used with, and reuse some common pieces of code.

public abstract class AMeterState
{
    protected Meter meter;

    public abstract void PowerOn();
    public abstract void Start(uint _time);
    public abstract void PowerOff();

    public AMeterState(Meter _meter)
    {
        meter = _meter;
    }

    public virtual void TopUp(uint _value)
    {
        meter.AddCredit(_value);
        Console.WriteLine("* Your meter has been topped up by {0} credits!", _value.ToString());
        Console.WriteLine("  Current credit: {0}", meter.Credit.ToString());
        if (meter.Credit > 0) { meter.CurrentState = meter.OnState; }
        else { meter.CurrentState = meter.MinusState; }
    }

    public void ReachZero()
    {
        Console.WriteLine("* You have used up all credits. Please top up!");
        meter.CurrentState = meter.MinusState;
    }
}

public abstract class AMeterState

{

protected Meter meter;

public abstract void PowerOn();

public abstract void Start(uint _time);

public abstract void PowerOff();

public AMeterState(Meter _meter)

{

meter = _meter;

}

public virtual void TopUp(uint _value)

{

meter.AddCredit(_value);

Console.WriteLine("* Your meter has been topped up by {0} credits!", _value.ToString());

Console.WriteLine(" Current credit: {0}", meter.Credit.ToString());

if (meter.Credit > 0) { meter.CurrentState = meter.OnState; }

else { meter.CurrentState = meter.MinusState; }

}

public void ReachZero()

{

Console.WriteLine("* You have used up all credits. Please top up!");

meter.CurrentState = meter.MinusState;

}

As you can see states will have all the methods that the meter will call in different states. The TopUp() methods has default implementation because it will the same for OnState and MinusState, method ReachZero will be called whenever the meter runs out of credit. It doesn’t need to be virtual because no override will ever be needed.
The last pieces of code would be actual implementations of the sates. Let’s take a look at just one:

public class OnState : AMeterState
{
    public OnState(Meter _meter)
        : base(_meter) { }

    public override void PowerOff()
    {
        Console.WriteLine("* Meter turned off.");
        meter.CurrentState = meter.OffState;
    }

    public override void PowerOn()
    {
        Console.WriteLine("* Meter already on.");
    }

    public override void Start(uint _time)
    {
        Console.WriteLine("* Starting the meter");
        while ((_time > 0) && (meter.Credit > 0))
        {
            _time--;
            meter.TakeCredit();
            Console.WriteLine("  Powering appliances...");
        }
        if (_time <= 0) { Console.WriteLine("* Meter has completed providing power for requested cycles."); }
        if (meter.Credit <= 0) { ReachZero(); }
    }
}

public class OnState : AMeterState

{

public OnState(Meter _meter)

: base(_meter) { }

public override void PowerOff()

{

Console.WriteLine("* Meter turned off.");

meter.CurrentState = meter.OffState;

}

public override void PowerOn()

{

Console.WriteLine("* Meter already on.");

}

public override void Start(uint _time)

{

Console.WriteLine("* Starting the meter");

while ((_time > 0) && (meter.Credit > 0))

{

_time--;

meter.TakeCredit();

Console.WriteLine(" Powering appliances...");

}

if (_time <= 0) { Console.WriteLine("* Meter has completed providing power for requested cycles."); }

if (meter.Credit <= 0) { ReachZero(); }

}

As you can see each state provide its own implementation of actions possible for the meter (except for TopUp() which as stated earlier can be shared and in this case it is, but it isn’t in OffState where it is overridden to simply write out on console that the meter is off). Note that some of them changes the state – that’s the core of this pattern: the internal change of state.
Having all the states implemented we can see how it works:

static void Main(string[] args)
{
    IMeter meter = new Meter(); //initialize new meter which is in off state
    meter.PowerOn(); //power the meter up
    meter.Start(10); //try to start the meter for 10 cycles which fails due to lack of credit
    meter.TopUp(12); //top up by 6 credits
    meter.Start(10); //start the meter for 10 cycles
    meter.Start(5); //start the meter for 5 cycles which should use up all credits and terminate prematurely
    meter.PowerOff(); //power of the meter
}

static void Main(string[] args)

{

IMeter meter = new Meter(); //initialize new meter which is in off state

meter.PowerOn(); //power the meter up

meter.Start(10); //try to start the meter for 10 cycles which fails due to lack of credit

meter.TopUp(12); //top up by 6 credits

meter.Start(10); //start the meter for 10 cycles

meter.Start(5); //start the meter for 5 cycles which should use up all credits and terminate prematurely

meter.PowerOff(); //power of the meter

}

The above would generate output like this:
As you can see we invoked Start() method on one and the same object and we got three different results which all depended on the state in which the object had been, and some of which changed the state of the object. That’s the way how the state pattern works.

Before I prepared this example I had prepared another: a model of vending machine. It is a WPF app. The reason I decided to go for something different was the fact that it had become a bit unclear in the code. Simple console app is much better to illustrate the pattern. However I did not abandoned the code and you can take a look at this as well. Here’s quick video how it works and the source code you will find at the bottom of this post.

So that’s it for today. Hope you like it 🙂 Before you go please find some useful links below. Enjoy!

Source code – IMeter: TXT file
Source code – Vending machine: GitHub

Design Patterns #9: Composite

Design patterns episode 9 – Composite

With unexpected delay but patterns are back! In this episode – composite.

The composite is generally used to model tree-like structures in a way that classes that are using the composite can handle its elements in one particular way without having to distinguish whether an element has children – a composite, or hasn’t – a leaf (in other words, whether we can go further down the tree or element is a dead-end).

The first thing that comes up when thinking about that kind of structure would be a directory tree where folders are composites and files are leafs. Or any other structure alike: corporate structure (managers and subordinates), online shops (categories and concrete items) and many many more.

DEFINITION
Let’s see how the Head First book defines this pattern:

The Composite Pattern allows you to compose objects into tree structures to represent part-whole hierarchies. Composite lets client treat individual objects and composition of objects uniformly.
(Freeman, Eric, et al. Head First Design Patterns. O’Reilly Media, Inc. 2004)

So, in other words we have tree structure of objects and collection of objects and the client doesn’t need to care about if it’s a leaf or a composite. This is the key feature of this pattern. For instance, let’s think about file system where we have files and directories. Both of them are elements of file system and should be treated the same: the client can perform the same operations on both – rename, delete, get size etc. But obviously we can do more things with directories (as this is a collection of files and directories), therefore composite pattern isn’t applicable here (of course you could use typecasting to make it work but that’s a different thing).
The diagram shows what discussed above – both concretions are treated the same, nothing different can client do with one or the other type. The diagram presented here is different than what’s in the book. The book adds further methods: add(), remove(), getChild(). But isn’t that inconsistent with the definition? How can you add a further child to a leaf? You could throw an exception but wouldn’t that violate the Interface Segregation Principle? That kind of issues have been greatly discussed here by the guy who I quoted on multiple occasions.
So, to conclude this aspect of the pattern – my opinion is that we should stick to ISP and not force any class to implement something that the class doesn’t use. Period. Let’s move on to code example.

EXAMPLE

In our code example we’re going to build a store’s menu. Let’s start with the abstraction:

public interface IStoreElement
{
    string Name { get; set; }
    string ListOut(int indent = 0);
}

public interface IStoreElement

{

string Name { get; set; }

string ListOut(int indent = 0);

}

Our IStoreElement consist of name property and a method to list self in the menu: there will be different implementations of this method for leaves and composites. This method can take optional argument as we want to nicely format the menu by indentation of sub-components.
Now the leaf class:

public class StoreItem : IStoreElement
{
    public string Name { get; set; }

    public StoreItem(string _name)
    {
        Name = _name;
    }

    public string ListOut(int indent = 0)
    {
        string result = "";
        for (int i = indent; i > 0; i--)
        {
            result += "-";
        }
        result += String.Format("Item: {0}", Name);
        return result;
    }
}

public class StoreItem : IStoreElement

{

public string Name { get; set; }

public StoreItem(string _name)

{

Name = _name;

}

public string ListOut(int indent = 0)

{

string result = "";

for (int i = indent; i > 0; i--)

{

result += "-";

}

result += String.Format("Item: {0}", Name);

return result;

}

Leaf’s implementation of ListOut() method works that it returns a string with given number of dashes and its name.
And finally composite class:

public class StoreCategory : IStoreElement
{
    public string Name { get; set; }
    private IList<IStoreElement> members;

    public StoreCategory(string _name, IList<IStoreElement> _members)
    {
        Name = _name;
        members = _members;
    }

    public string ListOut(int indent = 0)
    {
        string result = "";
        for (int i = indent; i > 0; i--)
        {
            result += "-";
        }
        result += String.Format("Category: {0}", Name);
        foreach (IStoreElement element in members)
        {
            result += String.Format("\n{0}", element.ListOut(indent + 1));
        }
        return result;
    }
}

public class StoreCategory : IStoreElement

{

public string Name { get; set; }

private IList<IStoreElement> members;

public StoreCategory(string _name, IList<IStoreElement> _members)

{

Name = _name;

members = _members;

}

public string ListOut(int indent = 0)

{

string result = "";

for (int i = indent; i > 0; i--)

{

result += "-";

}

result += String.Format("Category: {0}", Name);

foreach (IStoreElement element in members)

{

result += String.Format("\n{0}", element.ListOut(indent + 1));

}

return result;

}

This class is equipped with private list of objects that implement our base interface. This list can be set in constructor.
The ListOut() method starts with the same thing that counterparting method in leaves but before returning the value recursively invokes the same method for all IStoreElements that the composite holds in its private list. This invocation takes indent parameter increased by 1. This way we achieve that nice formatting of the list once requested in the topmost component.
Now, let’s see how it work all together:

static void Main(string[] args)
{
    IStoreElement myStore = generate();
    Console.WriteLine(myStore.ListOut());
}

static IStoreElement generate()
{
    IStoreElement subcat1 = new StoreCategory("Foods",
        new List<IStoreElement>
        {
                    new StoreItem("Bread"),
                    new StoreItem("Veggies"),
                    new StoreItem("Cheese"),
                    new StoreCategory("Drinks",
                    new List<IStoreElement>
                    {
                        new StoreItem("Juice"),
                        new StoreItem("Mineral water"),
                    })
        });
    IStoreElement subcat2 = new StoreCategory("Chems",
        new List<IStoreElement>
        {
                    new StoreItem("Toothpaste"),
                    new StoreItem("Shampoo"),
                    new StoreItem("Soap")
        });
    IStoreElement item1 = new StoreItem("Painkillers");
    IStoreElement item2 = new StoreItem("Lottery ticket");
    IStoreElement result = new StoreCategory("Local shop",
        new List<IStoreElement>
        {
                    subcat1,
                    subcat2,
                    item1,
                    item2
        });
    return result;
}

static void Main(string[] args)

{

IStoreElement myStore = generate();

Console.WriteLine(myStore.ListOut());

}

static IStoreElement generate()

{

IStoreElement subcat1 = new StoreCategory("Foods",

new List<IStoreElement>

{

new StoreItem("Bread"),

new StoreItem("Veggies"),

new StoreItem("Cheese"),

new StoreCategory("Drinks",

new List<IStoreElement>

{

new StoreItem("Juice"),

new StoreItem("Mineral water"),

})

});

IStoreElement subcat2 = new StoreCategory("Chems",

new List<IStoreElement>

{

new StoreItem("Toothpaste"),

new StoreItem("Shampoo"),

new StoreItem("Soap")

});

IStoreElement item1 = new StoreItem("Painkillers");

IStoreElement item2 = new StoreItem("Lottery ticket");

IStoreElement result = new StoreCategory("Local shop",

new List<IStoreElement>

{

subcat1,

subcat2,

item1,

item2

});

return result;

}

We generate the list and then print to the console the string returned by ListOut().

To sum things up: he Composite Pattern is used to represent tree-like structures where all their elements can be treated uniformly, where single components are called leaves and collections of components are called composites. The pattern can be equipped with methods to modify the content but this lead to violation of Interface Segregation Principle.

Next week: the State Pattern. I hope that this time without any delay. Check the links and source code below. Thank you!

Composite pattern by Christopher Okhravi: link [YouTube]
Composite vs. Decorator by Christopher Okhravi: link [YouTube]
Composite pattern by Michael: link [YouTube]
Source code: TXT file

Design Patterns #8: Iterator

Design patterns episode 8 – Iterator

Today’s pattern is the Iterator – an easy way to cycle through collections without worrying how it is achieved – in simple words. Let’s see what the Head First book has to say about that.

DEFINITION

The Iterator Pattern provides a way to access the elements of an aggregate object sequentially without exposing its underlying implementation.
(Freeman, Eric, et al. Head First Design Patterns. O’Reilly Media, Inc. 2004)

This is achieved by two interfaces: one abstracts the iterator, the other abstracts the aggregator. To make things clear – the aggregator is a class that provides a collection we want to iterate through.

So, there is a class called ConcreteAggregator that has a collection of objects. The diagram above depicts a generic version of the pattern (this not a must, you can write your own specific iterator) so the collection stores objects of type T. The ConcreteAggregator doesn’t want to allow direct access to that collection so it implements the IAggregator interface to allow the client to use the iterator by invoking GetIterator() method which returns ConcreteIterator which in turn implements the IIterator interface. This interface is the core of the pattern: it provides methods to actually iterate through the collection: i) Reset() to move index pointer to the start of the collection, ii) HasNext() to indicate whether there are more elements in the collection, and finally iii) Next() to get an element from the collection.

ITERATORS IN .NET

The .NET Framework uses this pattern widely in collections. To make long story short – in System.Collections (or System.Collections.Generic) namespace you can find IEnumerable interface which has only one method: GetEnumerator() – sounds familiar, right? Most of the collections implement this interface – Lists or dictionaries for instance, not to look far. This method returns an object the implement IEnumerator interface. In this case this interface is slightly different:

This post	.NET namespaces	Explanation
void Reset()	void Reset()	no difference
bool HasNext()	bool MoveNext()	In .NET interface this method moves the pointer to next element and returns: true – if advanced successfully without passing the end, false – if passed the last element and set the pointer to the first element
<T> Next()	object or <T> Current { get; }	In .NET this property returns object at current position of the pointer without moving to next element

EXAMPLE

In the example we will create a book library. This class will store books in a private list but will expose an iterator. Let’s start with the interfaces:

public interface IIterator<T>
{
    void Reset();
    bool HasNext();
    T Next();
}

public interface IAggregator<T>
{
    IIterator<T> GetIterator();
}

public interface IIterator<T>

{

void Reset();

bool HasNext();

T Next();

}

public interface IAggregator<T>

{

IIterator<T> GetIterator();

}

They’ve been already discussed above so the only thing I would like you to pay attention to is the fact that they’re generic.
Next step – implement the iterator:

public class LibraryIterator : IIterator<string>
{
    private string[] books;
    private int currentIndex;

    public LibraryIterator(IList<string> _books)
    {
        currentIndex = 0;
        books = new string[_books.Count];
        for (int i = 0; i < books.Length; i++)
        {
            books[i] = _books[i];
        }
        Reset();
    }

    public void Reset()
    {
        currentIndex = -1;
    }

    public bool HasNext()
    {
        if (books.Length > currentIndex + 1) { return true; }
        return false;
    }

    public string Next()
    {
        try
        {
            currentIndex++;
            return books[currentIndex];
        }
        catch
        {
            Reset();
            return Next();
        }
    }
}

public class LibraryIterator : IIterator<string>

{

private string[] books;

private int currentIndex;

public LibraryIterator(IList<string> _books)

{

currentIndex = 0;

books = new string[_books.Count];

for (int i = 0; i < books.Length; i++)

{

books[i] = _books[i];

}

Reset();

}

public void Reset()

{

currentIndex = -1;

}

public bool HasNext()

{

if (books.Length > currentIndex + 1) { return true; }

return false;

}

public string Next()

{

try

{

currentIndex++;

return books[currentIndex];

}

catch

{

Reset();

return Next();

}

To complicate the code a bit the implementation will use an array to store the values, beside that we also have an integer to indicate current position. In the constructor we initialise the array of values and copy them from the list passed as an argument. The last thing we need to do in the constructor is to set the index indicator to Reset() the position indicator. The only thing that Reset() method do is to set value of position indicator to -1. Why -1 not 0? That is because we use Next() method to get values: this method first increments the indicator and then extracts the value. Method HasNext() simply check if position index increment operation would not exceed the length of the array of values.

public class Library : IAggregator<string>
{
    private List<string> books;

    public Library()
    {
        books = new List<string>()
            {
                "Lord of the Rings",
                "Dune",
                "Brave New World",
                "The Road",
                "20.000 Leagues Under the Sea",
                "The Call of Cthulhu",
                "Bloody Meridian"
            };
    }

    public IIterator<string> GetIterator()
    {
        return new LibraryIterator(books);
    }
}

public class Library : IAggregator<string>

{

private List<string> books;

public Library()

{

books = new List<string>()

{

"Lord of the Rings",

"Dune",

"Brave New World",

"The Road",

"20.000 Leagues Under the Sea",

"The Call of Cthulhu",

"Bloody Meridian"

};

}

public IIterator<string> GetIterator()

{

return new LibraryIterator(books);

}

The Library class is very simple – in its constructor we fill the list of books and implement the IAggregator interface: the GetIterator() method returns new LibraryIterator with list of books passed as an argument.
And everything works perfectly. Here’s some code to test that:

static void Main(string[] args)
{
    IAggregator<string> myLib = new Library();
    IIterator<string> myLibIterator = myLib.GetIterator();

    while (myLibIterator.HasNext()) // iterating through
    {
        Console.WriteLine(myLibIterator.Next());
    }

    Console.WriteLine("---\nHas next: {0}", myLibIterator.HasNext()); // HasNext() is false when reached the last element

    Console.WriteLine("---\nNext element: {0}", myLibIterator.Next()); // what happens when tried Next() method

    Console.WriteLine("---\nNext element: {0}", myLibIterator.Next()); // what happens when tried Next() method

    Console.WriteLine("---\nNext element: {0}", myLibIterator.Next()); // what happens when tried Next() method

    Console.WriteLine("---\nHas next: {0}", myLibIterator.HasNext()); // what happens when tried HasNext() in the middle of the iterator

    myLibIterator.Reset();

    Console.WriteLine("---\nNext element: {0}", myLibIterator.Next()); // what happens when tried Next() after Reset();

    Console.WriteLine("---\nNext element: {0}\n---", myLibIterator.Next()); // what happens when tried Next() method

    while (myLibIterator.HasNext()) // iterating through again this time starting not from the begining
    {
        Console.WriteLine(myLibIterator.Next());
    }
}

static void Main(string[] args)

{

IAggregator<string> myLib = new Library();

IIterator<string> myLibIterator = myLib.GetIterator();

while (myLibIterator.HasNext()) // iterating through

{

Console.WriteLine(myLibIterator.Next());

}

Console.WriteLine("---\nHas next: {0}", myLibIterator.HasNext()); // HasNext() is false when reached the last element

Console.WriteLine("---\nNext element: {0}", myLibIterator.Next()); // what happens when tried Next() method

Console.WriteLine("---\nHas next: {0}", myLibIterator.HasNext()); // what happens when tried HasNext() in the middle of the iterator

myLibIterator.Reset();

Console.WriteLine("---\nNext element: {0}", myLibIterator.Next()); // what happens when tried Next() after Reset();

Console.WriteLine("---\nNext element: {0}\n---", myLibIterator.Next()); // what happens when tried Next() method

while (myLibIterator.HasNext()) // iterating through again this time starting not from the begining

{

Console.WriteLine(myLibIterator.Next());

}

And that’s it – the iterator in its full swing:
Here’s couple of links that may also be useful:
Why iterator is important: [YouTube] by Christopher Okhravi
Another code example: [YouTube] by Michael

Source code: [TXT file]

Design Patterns #7: Template Method

Design patterns episode 7 – Template Method

This post is about template method pattern. Those who are familiar with the Head First book may be wondering where’s facade. The answer to that question is that I deliberately decided to skip the facade at this point. I will definitely come back to this, but maybe next time. Now, let’s move on to the template method.

DEFINITION

The Template Method pattern defines the skeleton of an algorithm in a method, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm’s structure.
(Freeman, Eric, et al. Head First Design Patterns. O’Reilly Media, Inc. 2004)

What the above mean? It means that the pattern is built on base abstract class which has a public method which defines our algorithm by invoking in intended order some other methods which may be overridden by subclasses. The algorithm’s member methods may provide default implementation of be abstract forcing the subclasses to provide their own unique implementation.

EXAMPLE
Most of the examples you can find is based on preparation of pizza, coffee etc. And they’re really good. Pizza for instance: when you’re cooking a pizza no matter what style you basically do the same: prepare dough, add sauce, toppings, put it into oven and cut. That’s the algorithm. But you certainly do different dough for American pizza and for traditional Italian pizza, you add different toppings for vegetarian pizza and for meat pizza – and that’s the where we may want to override our sub-methods of the algorithm.

The code below will not be about pizzas, it’s going to be a generic code that does nothing but show how the pattern may be implemented.
Let’s take a look at our base class:

public abstract class TemplateBase
{
    public void TemplateMethod()
    {
        subOperation0();
        subOperation1();
        subOperation2();
        if (ExecuteOptional) { subOperation3(); }
    }

    public void subOperation0()
    {
        Console.WriteLine("Start:\nOperation 0 - cannot be overridden");
    }

    public virtual void subOperation1()
    {
        Console.WriteLine("Operation 1");
    }

    public abstract void subOperation2();

    public virtual void subOperation3()
    {
        Console.WriteLine("Operation 3 - optional");
    }

    public bool ExecuteOptional
    {
        get;
        set;
    }
}

public abstract class TemplateBase

{

public void TemplateMethod()

{

subOperation0();

subOperation1();

subOperation2();

if (ExecuteOptional) { subOperation3(); }

}

public void subOperation0()

{

Console.WriteLine("Start:\nOperation 0 - cannot be overridden");

}

public virtual void subOperation1()

{

Console.WriteLine("Operation 1");

}

public abstract void subOperation2();

public virtual void subOperation3()

{

Console.WriteLine("Operation 3 - optional");

}

public bool ExecuteOptional

{

get;

set;

}

As you can see our TemplateMethod() is not marked as virtual therefore it cannot be overridden – this is the skeleton of the algorithm. In its body this method invoke all member methods – subOperations from 0 to 3. Interesting thing is that the last member method will be executed only if a condition is true. This is called a hook. This is one way to alter the invocation list of the algorithm. You don’t need to use is but it’s good to know. Besides that we have combination of methods with default implementation, abstract methods and those you cannot overwrite. In our case only one methods needs to be implemented in a subclass – let’s take look:

public class ConcreteTemplate : TemplateBase
{
    public override void subOperation1()
    {
        Console.WriteLine("Overriden operation 1");
    }

    public override void subOperation2()
    {
        Console.WriteLine("Operation 2 - does not have default implementation");
    }
}

public class ConcreteTemplate : TemplateBase

{

public override void subOperation1()

{

Console.WriteLine("Overriden operation 1");

}

public override void subOperation2()

{

Console.WriteLine("Operation 2 - does not have default implementation");

}

So, our concrete implementation overwrites one method with implementation in base class and provides implementation of one abstract class. Simple, so let’s see how it works:

static void Main(string[] args)
{
    TemplateBase tm = new ConcreteTemplate();
    tm.TemplateMethod();
    tm.ExecuteOptional = true;
    tm.TemplateMethod();
}

static void Main(string[] args)

{

TemplateBase tm = new ConcreteTemplate();

tm.TemplateMethod();

tm.ExecuteOptional = true;

tm.TemplateMethod();

}

To witness the template method we instantiate new ConcreteTemplate and observe how it behaves – with optional method executed and without.

And that’s the template method pattern. The best explanation of this pattern I’ve found so far is in the Head First book but below you will find also one link to a YouTube video with Phil Japikse – you may find it useful.
Thanks for today and expect the next pattern next week.

Design Patterns: Template Method – YouTube
Source code: TXT file

Design Patterns #6: Adapter

Continuing with design patterns. Time for Adapter. This pattern is a structural pattern whose purpose is to convert interface (in a meaning of public members of the class, not necessarily interface as a programming language feature) so the class is usable with client’s code. The Head First book defines this pattern as:

The Adapter Pattern converts the interface of a class into another interface the client expects. Adapter lets classes work that couldn’t otherwise because of incompatible interfaces.
(Freeman, Eric, et al. Head First Design Patterns. O’Reilly Media, Inc. 2004)

Generally, it may be said that the adapter pattern wraps an object that cannot be used by a client and exposes an interface that allow the client to use that object. Let’s take a look at the diagram:

So, we have a client that wants to use an object that implements IExpected interface, however we already have a class that does what we need but doesn’t have a compatible interface (unsupported class). So, to solve the problem we need an adapter. The adapter will have all public members that the client expects – will implement the IExpected interface and at the same time will privately wrap an instance of unsupported class (passed in a constructor, for instance). Once the client calls the adapter, the adapter will in turn call the wrapped unsupported class and return results to the client (and if required convert them to what the client expects). And that’s it, simple as that.

EXAMPLE
Let’s take a look at code example now. We have a class that calculates area and perimeter of a rectangle. (These calculations are very simple but to give the example a little bit more depth think of them as of very sophisticated and complicated). That class operates on double type. Our client, however wants to calculate area and perimeter of squares only and operates on integers. We could i) write a new class to handle that but we don’t want to do that because we already have a class that is capable to perform such calculations (square is a rectangle after all, right?); ii) modify our client to work with the existing class, but again we don’t want to break anything elsewhere (OCP right?). That’s why the right solution here is the adapter.
Let’s compare what we have and what we need:

public class RectangleHandler
{
    public double Area(double a, double b)
    {
        return a * b;
    }

    public double Perimeter(double a, double b)
    {
        return 2 * a + 2 * b;
    }
}

public class RectangleHandler

{

public double Area(double a, double b)

{

return a * b;

}

public double Perimeter(double a, double b)

{

return 2 * a + 2 * b;

}

public interface ISquareHandler
{
    int GetArea(int a);
    int GetPerimeter(int a);
}

public interface ISquareHandler

{

int GetArea(int a);

int GetPerimeter(int a);

}

So, the differences are: i) types (already mentioned int vs. double), ii) method names, iii) number or arguments required for counterparting methods.
Now the adapter. First of all it needs to wrap the already existing class and set its instance by passing it through constructor; then we need to implement methods required by IExpected interface in a way that they call the wrapped object and return values converted to integers.

public class RectangleAdapter : ISquareHandler
{
    private RectangleHandler adaptedHandler;

    public RectangleAdapter(RectangleHandler _adapted)
    {
        adaptedHandler = _adapted;
    }

    public int GetArea(int a)
    {
        int result = (int)adaptedHandler.Area((double)a, (double)a);
        return result;
    }

    public int GetPerimeter(int a)
    {
        int result = (int)adaptedHandler.Perimeter((double)a, (double)a);
        return result;
    }
}

public class RectangleAdapter : ISquareHandler

{

private RectangleHandler adaptedHandler;

public RectangleAdapter(RectangleHandler _adapted)

{

adaptedHandler = _adapted;

}

public int GetArea(int a)

{

int result = (int)adaptedHandler.Area((double)a, (double)a);

return result;

}

public int GetPerimeter(int a)

{

int result = (int)adaptedHandler.Perimeter((double)a, (double)a);

return result;

}

Let’s write a quick test:

static void Main(string[] args)
{
    ISquareHandler squareHandler = new RectangleAdapter(new RectangleHandler());
    Console.WriteLine("Square edge length:");
    int length = int.Parse(Console.ReadLine());
    int area = squareHandler.GetArea(length);
    int perimeter = squareHandler.GetPerimeter(length);
    Console.WriteLine("Square: {0}x{0}", length);
    Console.WriteLine("Area: {0}", area);
    Console.WriteLine("Perimeter: {0}", perimeter);
}

static void Main(string[] args)

{

ISquareHandler squareHandler = new RectangleAdapter(new RectangleHandler());

Console.WriteLine("Square edge length:");

int length = int.Parse(Console.ReadLine());

int area = squareHandler.GetArea(length);

int perimeter = squareHandler.GetPerimeter(length);

Console.WriteLine("Square: {0}x{0}", length);

Console.WriteLine("Area: {0}", area);

Console.WriteLine("Perimeter: {0}", perimeter);

}

Everything works perfectly.

Object adapter vs. Class adapter
The explanation and code example is an object adapter. This means that the adapter works with a concrete instance of adapted object. Advantage of this solution is that this type of adapter will work also with objects of classes which are derived from adapted superclass.
There is also another adapter-type pattern called class adapter. In this type you don’t need an instance of adapted class, instead the adapter class inherits from both: expected class (or interface) and adapted class. Remember that inheriting from more than one superclass is not possible, what could be done is to create new class that inherits from a class that needs to be adapted and implements expected interface. This approach may also be useful but keep in mind that it looses the advantage of composition over inheritance.

To sum things up: adapters are extremely useful everywhere there is a need to use something that can do what we need but doesn’t have compatible interface.
Plan for next week: Facade

Don’t forget to check the links below!

Christopher Okhravi about Adapter Pattern: [YouTube]
Source code: [TXT file]

Design Patterns #5: Command

Fogadtatás,
delayed but here I am with the next design pattern. This time it’s the command pattern. Those who are familiar with the Head First book might be wondering where’s singleton. The Some time ago I wrote a post about singleton (which you can find [here]), so there’s no point in going back. Therefore we go straight to the command.

The command pattern encapsulate calls to objects and provides undo mechanism for those calls. This is achieved by command classes which can perform an action over an object and are assigned to callers. Let’s take a look at the diagram:

Let’s start discussing the above from the ICommand interface and its concrete implementation. The interface has two methods: one for proper action, one for undoing the action. The implementation additionally has reference to IReciever object which defines over what type the command can execute. This is not mandatory, for instance you can declare your execute() and undo() methods to take IReciever as parameter. The important thing is that concrete command operates on certain type, however the caller doesn’t know anything about the receiver, the only responsibility of the caller is (so to speak) to call.

The example in the book is really great. The authors presented a programmable remote controller for an intelligent house. The controller has multiple buttons which can be assigned with a command that can operate lights, home cinema etc.

EXAMPLE
Our example will be programmable counter. The counter will have 5 buttons to manipulate the value of the counter. The counter will have undo feature. This time the code example will have WinForms GUI with custom controls for buttons-callers and counter-receiver.

The caller will have a button to execute a command and a drop-down list to ‘program’ the button with one of the available commands.

The receiver will have a text-box with current value, button to reset the counter, button to undo last command and a list of all executed commands (operating in FIFO-like mode, the newest on top, the newest first to undo). This user-control will also implement IReceiver interface which provides integer property CounterValue (which play the role of action() method from the diagram) on which the commands will operate and AddToTrace methods which will be used by a command to enroll itself to a command trace for undoing.

public interface IReciever
{
    int CounterValue { get; set; }

    void AddToTrace(ICommand _command);
}

public interface IReciever

{

int CounterValue { get; set; }

void AddToTrace(ICommand _command);

}

Now, the command. Let’s start with the interface:

public interface ICommand
{
    string Name { get; set; }
    IReciever Reciever { get; set; }

    void Execute();
    void Undo();
}

public interface ICommand

{

string Name { get; set; }

IReciever Reciever { get; set; }

void Execute();

void Undo();

}

Beside two already discussed methods Execute() and Undo() the interface provides also Name property (which will be used by the UI) and Receiver property for referencing the counter on which the command will operate.

Concrete command
Now, let’s take a look at one of the commands which implements ICommand interface:

public class CommandAddOne : ICommand
{
    public string Name { get; set; }
    public IReciever Reciever { get; set; }

    public void Execute()
    {
        Reciever.CounterValue += 1;
        Reciever.AddToTrace(this);
    }

    public void Undo()
    {
        Reciever.CounterValue -= 1;
    }

    public CommandAddOne(IReciever _reciever)
    {
        Name = "Add 1";
        Reciever = _reciever;
    }
}

public class CommandAddOne : ICommand

{

public string Name { get; set; }

public IReciever Reciever { get; set; }

public void Execute()

{

Reciever.CounterValue += 1;

Reciever.AddToTrace(this);

}

public void Undo()

{

Reciever.CounterValue -= 1;

}

public CommandAddOne(IReciever _reciever)

{

Name = "Add 1";

Reciever = _reciever;

}

The Execute() method increments the value of the counter and puts the command to the top of the command trace for undoing. The Undo() method simply does the opposite of the Execute() method which is to decrease the counter by one. Removing it from the command trace will be the responsibility of the undo button in the counter user-control.

Command trace
To make it possible we need to keep track of what commands have been executed. For that reason our counter user-control is equipped with a private list that holds objects of type ICommand. The command can enrol itself to the list by invoking AddToTrace method of the receiver and pass itself as an argument.

public void AddToTrace(ICommand _command)
{
    commandTrace.Insert(0, _command);
    updateTrace(); //this method updates the UI
}

public void AddToTrace(ICommand _command)

{

commandTrace.Insert(0, _command);

updateTrace(); //this method updates the UI

}

Once we have the list we can use the undo button which takes the first element off the command trace and invokes the Undo() method.

And that’s it. Take a look how this operates.

So, that’s it for today. Don’t forget about the source code below and come back next week!

Source code: ZIP file

Design Patterns #4: Factories

Hello there!
It already is a weekend so time for next pattern from the list: factories. Factories are creational-type patterns which means they are used to (surprise, surprise) to create instances. There are three types of factories (of which only latter two are considered as design patterns): simple factory, factory method and abstract factory. Let’s start with the non-pattern one.

SIMPLE FACTORY
Simple factory is a class that has a method to create a certain types of objects where the decision what exactly type to create is made by the factory itself based on given parameters. Assume that we’re building a book store and we want to sell paperbooks, audiobooks and ebooks. We have definitions of a sub-class for each of them implementing IBook base interface. We can build our simple factory in a way that we pass a char parameter and if it matches with first letter of our sub type we create that sub-type:

public class SimpleBookFactory
{
    public IBook CreateBook(char _type, string _author, string _title)
    {
        IBook book;
        switch (_type)
        {
            case 'a':
                book = new Audiobook();
                break;
            case 'e':
                book = new EBook();
                break;
            default:
                book = new Book();
                break;
        }
        book.Author = _author;
        book.Title = _title;
        return book;
    }
}

public class SimpleBookFactory

{

public IBook CreateBook(char _type, string _author, string _title)

{

IBook book;

switch (_type)

{

case 'a':

book = new Audiobook();

break;

case 'e':

book = new EBook();

break;

default:

book = new Book();

break;

}

book.Author = _author;

book.Title = _title;

return book;

}

And that’s it: we have our simple factory. But the problem is that when we want to introduce another sub-type it is necessary to modify that class. And we don’t want that. And why you find [here].

FACTORY METHOD
About factory method I’ve already written [one post]. Consider this post as a supplement to the previous one.
Factory method solves the issue we had with simple factory by removing it’s responsibility to decide (based on the parameter) what type exactly to create. If we want to modify the factory we’ve created above we would need to create separate classes responsible for creating each type of book. And that’s what was done in my [first post] about this pattern:

public abstract class BookFactory
{
    public abstract IBook CreateBook(string _author, string _title);
}

public class PaperFactory : BookFactory
{
    public override IBook CreateBook(string _author, string _title)
    {
        Book newBook = new Book { Author = _author, Title = _title, Pages = 0, IsHardcover = false };
        return newBook;
    }
}

public abstract class BookFactory

{

public abstract IBook CreateBook(string _author, string _title);

}

public class PaperFactory : BookFactory

{

public override IBook CreateBook(string _author, string _title)

{

Book newBook = new Book { Author = _author, Title = _title, Pages = 0, IsHardcover = false };

return newBook;

}

Now, if we need another sub-type we simply create another class that will create new sub-type.
Let’s take a look at the definition:

Factory method pattern defines an interface enabling to create a single object making the sub-class implementing this interface to decide what exactly type of object to create.

What does the above mean? It means that the client at the point of invocation of factory method doesn’t care (and doesn’t need to care) what type is going to be created: the client wants an object and is going to get one. Very good example is provided by Christopher Okhravi [here] – a simulator a national park where multiple types of animals dwell and the simulator care only about the right number of animals, when it needs an animal to spawn it just calls the factory and the factory decides what animal to create. (I’ve already said that multiple times but I highly recommend his [playlist] about design patterns.)
And now the UML:

We have an abstraction of factory method class and its concretion that creates an instance of a class which is a concretion of one interface common to all sub-types of product.

ABSTRACT FACTORY
If you know how the factory method works understanding the abstract factory will be a piece of cake. Let’s start with the definition:

Abstract Factory provides an interface for creating multiple related or dependent objects without necessity to define their concrete classes.

And the UML:

So, the client uses a factory to create instances. The factory is abstracted by the interface which has multiple (in the case above two) concretions which create two related sub-types of ProductA and ProductB. The IFactory interface doesn’t specify what concrete classes will be instantiated and the client doesn’t care. It is the concretion of the factory which specifies what sub-types of products exactly to create. So, in really really short we may say that the difference between factory method and abstract factory is that the former creates only one type objects while the latter can create multiple types of objects (related and/or dependent).

And that’s it. Before I say goodbye: have a look at the links below to find out more about factories; plan for next week – singleton.

Christopher Okhravi: Factory Method Pattern – Design Patterns (ep 4)
Christopher Okhravi: Abstract Factory Pattern – Design Patterns (ep 5)
CODE Project: Factory Patterns [Snesh Prajapati]

Design Patterns #3: Decorator

Design pattern number 3 – decorator. The decorator allows to dynamically modify behaviour of an object, and by ‘modify’ I not necessarily mean to swap completely.
The idea behind decorator pattern is that you take an object and wrap it with another object. Calling the outer object (decorator) will in turn call the inner object (component) and before returning any value will do its part with the value.

The example given in the book is a coffee shop where base coffee can be decorated with multiple toppings such as cream, sugar etc. And all those addition will make their own impact on price and name. The important is that the base product (component) and the decorator implements the same interface, the difference is that the decorator has a reference to the component.

And while the decorator itself can be a component it also can be decorated. And so on, and so on… Let’s take a look at the exemplary diagram: the decorator implements the component’s interface and has a reference to a component (we can say in short: the decorator has a component and is a component).

CODE EXAMPLE
Let’s now move on to the code example. My example will be similar to one presented in the book – orders that can be decorated with discounts, extra costs etc. So let’s start with abstractions.

Abstractions
Our IOrder interface will have its name and cost. Decorator interface will extend IOrder with property of IOrder type with public getter only.

public interface IOrder
{
    string Name { get; }
    int Cost { get; }
}

public interface IOrderDecorator : IOrder
{
    IOrder Component { get; }
}

public interface IOrder

{

string Name { get; }

int Cost { get; }

}

public interface IOrderDecorator : IOrder

{

IOrder Component { get; }

}

Implementations
Concrete classes will be very simple. Order class will have two automatic properties (with private setters) and a constructor that sets those properties.

public class Order : IOrder
{
    public string Name { get; private set; }

    public int Cost { get; private set; }

    public Order(string _name, int _cost)
    {
        Name = _name;
        Cost = _cost;
    }
}

public class Order : IOrder

{

public string Name { get; private set; }

public int Cost { get; private set; }

public Order(string _name, int _cost)

{

Name = _name;

Cost = _cost;

}

Things get a bit more complicated with the decorators. Here I will describe only one example but in the source code linked at the bottom of the page you will find two more (however they are very similar). The most important difference (as indicated already twice in this post ;)) is that the decorator has a reference to IOrder object. It will be set int he constructor. As this decorator’s purpose is to apply discount to the order we will need another property for that (of type int and it will also be set in the constructor). Now the essence of the pattern. As the decorator itself is of type IOrder we need to implement Cost and Name properties. These properties will call counterparting properties in referenced IOrder object, get their values and modify them appropriately. In this case the cost will be reduced by discount value and the name will be equipped with a suffix informing about the discount. We can build as many decorators as we please, and use them as many as we please.

public class DiscountedOrder : IOrderDecorator
{
    public int Discount { get; private set; }
    public IOrder Component { get; private set; }

    public string Name
    {
        get { return String.Format("{0}; discounted {1}%", Component.Name, Discount); }
    }

    public int Cost
    {
        get { return Component.Cost * (100 - Discount) / 100; }
    }

    public DiscountedOrder(IOrder _component, int _discount)
    {
        Discount = _discount;
        Component = _component ?? throw new ArgumentNullException();
    }
}

public class DiscountedOrder : IOrderDecorator

{

public int Discount { get; private set; }

public IOrder Component { get; private set; }

public string Name

{

get { return String.Format("{0}; discounted {1}%", Component.Name, Discount); }

}

public int Cost

{

get { return Component.Cost * (100 - Discount) / 100; }

}

public DiscountedOrder(IOrder _component, int _discount)

{

Discount = _discount;

Component = _component ?? throw new ArgumentNullException();

}

Usage
To test our orders and their decorators we’re gonna instantiate a pack of orders, decorate them and decorate again. They all will be stored in a list and then we will iterate through the list and print to screen their names and cost.

class Program
{
    static IList<IOrder> orders = new List<IOrder>();
    static void Main(string[] args)
    {
        IOrder baseOrder = new Order("Load", 100);
        orders.Add(baseOrder);
        IOrder deliveryOrder = new DeliveryChargeOrder(baseOrder, 10);
        orders.Add(deliveryOrder);
        IOrder discountedOrder = new DiscountedOrder(baseOrder, 10);
        orders.Add(discountedOrder);
        IOrder discountedOrderExtraCharged = new ExtraChargeOrder(discountedOrder, 20);
        orders.Add(discountedOrderExtraCharged);
        IOrder deliveryOrderDiscounted = new DiscountedOrder(deliveryOrder, 5);
        orders.Add(deliveryOrderDiscounted);
        orders.Add(new ExtraChargeOrder(new Order("New load", 200), 50));
        IOrder doubleDiscountedOrder = new DiscountedOrder(discountedOrderExtraCharged, 10);
        orders.Add(doubleDiscountedOrder);

        Console.WriteLine("Orders:");
        foreach (IOrder order in orders)
        {
            Console.WriteLine("-----");
            Console.WriteLine("Order name: {0}", order.Name);
            Console.WriteLine("Order cost: {0}", order.Cost);
        }
    }
}

class Program

{

static IList<IOrder> orders = new List<IOrder>();

static void Main(string[] args)

{

IOrder baseOrder = new Order("Load", 100);

orders.Add(baseOrder);

IOrder deliveryOrder = new DeliveryChargeOrder(baseOrder, 10);

orders.Add(deliveryOrder);

IOrder discountedOrder = new DiscountedOrder(baseOrder, 10);

orders.Add(discountedOrder);

IOrder discountedOrderExtraCharged = new ExtraChargeOrder(discountedOrder, 20);

orders.Add(discountedOrderExtraCharged);

IOrder deliveryOrderDiscounted = new DiscountedOrder(deliveryOrder, 5);

orders.Add(deliveryOrderDiscounted);

orders.Add(new ExtraChargeOrder(new Order("New load", 200), 50));

IOrder doubleDiscountedOrder = new DiscountedOrder(discountedOrderExtraCharged, 10);

orders.Add(doubleDiscountedOrder);

Console.WriteLine("Orders:");

foreach (IOrder order in orders)

{

Console.WriteLine("-----");

Console.WriteLine("Order name: {0}", order.Name);

Console.WriteLine("Order cost: {0}", order.Cost);

}

All works perfectly:

That’s it for today. Next week it will be time for factories. So I hope we see again!

Source code: download txt file

Design Patterns #2: Observer

Dzień dobry!
Continuing on design patterns – it’s time for the Observer. This pattern allows linkage between one observable and many observers that when the observable changes its states the observers are automatically notified and updated. So, the observable has a collection of observers, it performs its actions and when certain defined event happens it notifies its own observers. Let’s take a look at the diagram:

Let’s start with the observers: their interface defines only one method: Update(). That method returns void and can take parameters. In fact parameters are used to notify the actual change and not only the fact that the value has changed. It will be later shown in the example.
Now the observable: it must have possibility to add and remove observers (Register() and Unregister() methods respectively, as an argument they take object that implements IObserver interface) and to notify its observers about the change. Concrete implementation of the observable also has some sort of observers collection. (This collection is not part of the interface because a) it doesn’t have to be public, b) methods to register and unregister the observers are exposed publicly and that’s enough for the client, it doesn’t have to know how references to the observers are stored. Of course it doesn’t have to be like that. What we’re discussing here is just the pattern and its actual implementation may vary depending on every particular need.) Usual implementation of Notify() is iteration through the observers collection and invoking Update() method on each of them. And that’s it. Let’s go with the example.

EXAMPLE
Example given in the book (previous post explains what book) is a weather station (measures temperature, pressure etc.) and several types of display (current conditions, stats etc.) I think that’s a really good example but our example will be simpler but similar to some extent. We’re going to build number generator and two types of display.

Interfaces
Have a quick look at the code below:

public interface IObservable
{
    void Register(IObserver _observer);
    void Unregister(IObserver _observer);
}

public interface IObserver
{
    void Update(int _value);
}

public interface IObservable

{

void Register(IObserver _observer);

void Unregister(IObserver _observer);

}

public interface IObserver

{

void Update(int _value);

}

Hey, where’s Notify() method?! We don’t want that method to be exposed publicly therefore it won’t be here in the interface. As said earlier, the design patterns are not exact implementation nor have strict code structure, they are more of a general ways to achieve some result. But if you hear from another developer that he has used the observer pattern (or any other pattern) you will instantaneously know what to expect.
IObserver interface defines only one method which is Update() that takes one integer parameter which will be passed to our observers.

Concretions – Number Generator

public class NumberGenerator : IObservable
{
    private readonly int min, max;
    public int Last;
    private List<IObserver> observers;

    private Random rnd;

    public NumberGenerator(int _min, int _max)
    {
        min = _min;
        max = _max;
        observers = new List<IObserver>();
        rnd = new Random();
    }

    public void Next()
    {
        Last = rnd.Next(min, max);
        notify();
    }

    public void Register(IObserver _observer)
    {
        if (!observers.Contains(_observer)) { observers.Add(_observer); }
    }

    public void Unregister(IObserver _observer)
    {
        if (observers.Contains(_observer)) { observers.Remove(_observer); }
    }

    private void notify()
    {
        foreach (IObserver obs in observers)
        {
            obs.Update(Last);
        }
    }
}

public class NumberGenerator : IObservable

{

private readonly int min, max;

public int Last;

private List<IObserver> observers;

private Random rnd;

public NumberGenerator(int _min, int _max)

{

min = _min;

max = _max;

observers = new List<IObserver>();

rnd = new Random();

}

public void Next()

{

Last = rnd.Next(min, max);

notify();

}

public void Register(IObserver _observer)

{

if (!observers.Contains(_observer)) { observers.Add(_observer); }

}

public void Unregister(IObserver _observer)

{

if (observers.Contains(_observer)) { observers.Remove(_observer); }

}

private void notify()

{

foreach (IObserver obs in observers)

{

obs.Update(Last);

}

Our number generator will – surprise, surprise – generate random numbers within given range (which is specified by constructor’s parameters). It has list of objects of type IObserver and two methods that allow adding and removing from that list. Method notify() is private as we don’t want to make it possible from the outside of the class to force the observable to notify its observers. This method (as you can read above in this post) simply iterates through observers collection and invoke Update() method on each of them. This method is invoked inside Next() method which generates next random number. Parameter of the Update() method is last generated number.

Concretions – Observers

public class TotalDisplay : IObserver
{
    private int value;

    public TotalDisplay()
    {
        value = 0;
    }

    public void Update(int _updateValue)
    {
        value += _updateValue;
    }

    public void Display()
    {
        Console.WriteLine("Total: Current readings: {0}", value);
    }
}

public class AverageDisplay : IObserver
{
    private int count;
    private int total;

    private double avg
    {
        get
        {
            if (count == 0) { return 0; }
            return total / count;
        }
    }

    public AverageDisplay()
    {
        count = 0;
        total = 0;
    }

    public void Update(int _updateValue)
    {
        total += _updateValue;
        count++;
    }

    public void Display()
    {
        Console.WriteLine("Average: Current readings: {0}", avg);
    }
}

public class TotalDisplay : IObserver

{

private int value;

public TotalDisplay()

{

value = 0;

}

public void Update(int _updateValue)

{

value += _updateValue;

}

public void Display()

{

Console.WriteLine("Total: Current readings: {0}", value);

}

public class AverageDisplay : IObserver

{

private int count;

private int total;

private double avg

{

get

{

if (count == 0) { return 0; }

return total / count;

}

public AverageDisplay()

{

count = 0;

total = 0;

}

public void Update(int _updateValue)

{

total += _updateValue;

count++;

}

public void Display()

{

Console.WriteLine("Average: Current readings: {0}", avg);

}

These two implementations of IObserver using their Display() method print their current readings to console. One of them displays aggregated value of all random number passed from the observable, and the other displays average value. Their Update() are consistent with the interface they implement.

Wiring all together
All the above classes will work together in this small console app.

static void Main(string[] args)
{
    // initialize observable
    NumberGenerator numberGenerator = new NumberGenerator(0, 100);

    // intialize new displays
    TotalDisplay counterDisplay = new TotalDisplay();
    AverageDisplay averageDisplay = new AverageDisplay();

    // register displays as observers of number generator
    numberGenerator.Register(counterDisplay);
    numberGenerator.Register(averageDisplay);

    // perform generator cycle
    for (int i = 0; i < 10; i++)
    {
        Thread.Sleep(500);
        numberGenerator.Next();
        Console.WriteLine("Generated: {0}", numberGenerator.Last);
        counterDisplay.Display();
        averageDisplay.Display();
    }
}

static void Main(string[] args)

{

// initialize observable

NumberGenerator numberGenerator = new NumberGenerator(0, 100);

// intialize new displays

TotalDisplay counterDisplay = new TotalDisplay();

AverageDisplay averageDisplay = new AverageDisplay();

// register displays as observers of number generator

numberGenerator.Register(counterDisplay);

numberGenerator.Register(averageDisplay);

// perform generator cycle

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

{

Thread.Sleep(500);

numberGenerator.Next();

Console.WriteLine("Generated: {0}", numberGenerator.Last);

counterDisplay.Display();

averageDisplay.Display();

}

As you can see once we have an instance of NumberGenerator we can register some observers. Our console app will iterate 10 times and draw 10 random numbers and display readings of our observers.

Self-registration/unregistration
The example above shows basic implementation of the observer pattern. It may be improved by allowing object to self-register/unregister. This can be simply done by storing reference to observable in the observer. In this case observer will need appropriate methods: to register that takes observable as an argument, and to unregister with no arguments. Let’s take a look at its interface:

public interface ISelfRegistrationObserver : IObserver
{
    void SelfRegister(IObservable _observable);
    void SelfUnregister();
}

public interface ISelfRegistrationObserver : IObserver

{

void SelfRegister(IObservable _observable);

void SelfUnregister();

}

It extends existing IObserver interface and adds two methods as described earlier. Now, the concretion:

public class MaxDisplay : ISelfRegistrationObserver
{
    private int value;
    private IObservable observable;

    public MaxDisplay()
    {
        value = 0;
    }

    public void Display()
    {
        Console.WriteLine("Max: Current readings: {0}", value);
    }

    public void Update(int _value)
    {
        if (_value > value) { value = _value; }
    }

    public void SelfRegister(IObservable _observable)
    {
        if (observable == null)
        {
            observable = _observable;
            observable.Register(this);
        }
    }

    public void SelfUnregister()
    {
        if (observable != null)
        {
            observable.Unregister(this);
            observable = null;
        }
    }
}

public class MaxDisplay : ISelfRegistrationObserver

{

private int value;

private IObservable observable;

public MaxDisplay()

{

value = 0;

}

public void Display()

{

Console.WriteLine("Max: Current readings: {0}", value);

}

public void Update(int _value)

{

if (_value > value) { value = _value; }

}

public void SelfRegister(IObservable _observable)

{

if (observable == null)

{

observable = _observable;

observable.Register(this);

}

public void SelfUnregister()

{

if (observable != null)

{

observable.Unregister(this);

observable = null;

}

So, it now has a reference to the observer which initially is null. When we want to self-register it to a particular observer we simply invoke SelfRegister() method and pass the observer as an argument. The method will save the reference to the observer and invoke observer’s Register() method with this passed as an argument. SelfUnregister() method performs opposite actions. The code says it all 🙂
Below you will find to txt file with the source code. Thanks for today, and hopefully see you next week. Cheers!

Source code: download txt file

Design Patterns #1: Strategy

Nau mai!
Time for design patterns. Whenever I tried to find out anything about them I encountered this pretty good explanation what are they and why we need them:

Someone has already solved your problems.

‘Head First Design Patterns’ (page 1)

And after Wikipedia:

In software engineering, a software design pattern is a general reusable solution to a commonly occurring problem within a given context in software design. It is not a finished design that can be transformed directly into source or machine code. It is a description or template for how to solve a problem that can be used in many different situations. Design patterns are formalized best practices that the programmer can use to solve common problems when designing an application or system.

[source]

In a nutshell: common solutions to common problems. And that should be sufficient to start with first design pattern: Strategy. But, before that quick introduction to this series. It is inspired by Christopher Okhravi and his playlist. I will do basically the same: go through all design patterns in Head First Design Patterns book by Eric Freeman, Elisabeth Freeman, Bert Bates and Kathy Sierra. I have Polish edition but that does not make any difference for you, I will not give any quote in Polish (probably I won’t give any quote at all). To make this series somehow different and not to copy either the book or videos linked above I will use different examples. So, with that being sad we can cut to the chase.

Definition
Strategy defines common abstraction of set of algorithms, encapsulates them and make them reusable and interchangeable in run-time.

How is that achieved:

Define abstract class or interface that has one common method which invocation will perform some action
Define concretions for the above
Add variable of type strategy abstraction to your client class
Add method in your client class which will execute strategy

void executeAction() { ActionStrategy.execute(); }

1
2
3
4

void executeAction()
{
ActionStrategy.execute();
}

Add method in your client class that will allow to change strategy

void setStrategy(IStrategy _strategy)
{
this.ActionStrategy = _strategy;
}

void setStrategy(IStrategy _strategy)

{

this.ActionStrategy = _strategy;

}

And that’s basically it. Now, let’s move to example.

Example
Example given in book is a duck simulator. It uses different types of duck where actions such as quack or fly are abstracted and encapsulated into strategies. Good example in my opinion. Our example is magic box that consist of an array of 10 integers which can be displayed in console. But the way the numbers are displayed varies depending on enumeration strategy. Let’s start with abstracting the enumeration strategy:

public interface IEnumerateStrategy
{
    string Enumerate(int[] numbers);
}

public interface IEnumerateStrategy

{

string Enumerate(int[] numbers);

}

So, our strategy is used to return string that enumerates all numbers in given array.
Now, let’s implement different strategies: enumerate as is (without changing the order), bubble sorted and shuffled.

public class AsIsEnumerateStrategy : IEnumerateStrategy
{
    public string Enumerate(int[] numbers)
    {
        string output = "";
        for (int i = 0; i < numbers.Length - 1; i++)
        {
            output += numbers[i] + ", ";
        }
        output += numbers.Last();
        return output;
    }
}

public class AsIsEnumerateStrategy : IEnumerateStrategy

{

public string Enumerate(int[] numbers)

{

string output = "";

for (int i = 0; i < numbers.Length - 1; i++)

{

output += numbers[i] + ", ";

}

output += numbers.Last();

return output;

}

public class SortedEnumerateStrategy : IEnumerateStrategy
{
    public string Enumerate(int[] numbers)
    {
        int[] intArray = numbers.ToArray();
        int runs = 0;
        bool finished = true;
        do
        {
            finished = true;
            for (int i = 0; i < intArray.Length - 1 - runs; i++)
            {
                if (intArray[i] > intArray[i + 1])
                {
                    finished = false;
                    int buffer = intArray[i];
                    intArray[i] = intArray[i + 1];
                    intArray[i + 1] = buffer;
                }
            }
            runs++;
        }
        while (!finished);
        string output = "";
        for (int i = 0; i < intArray.Length - 1; i++)
        {
            output += intArray[i] + ", ";
        }
        output += intArray.Last();
        return output;
    }
}

public class SortedEnumerateStrategy : IEnumerateStrategy

{

public string Enumerate(int[] numbers)

{

int[] intArray = numbers.ToArray();

int runs = 0;

bool finished = true;

{

finished = true;

for (int i = 0; i < intArray.Length - 1 - runs; i++)

{

if (intArray[i] > intArray[i + 1])

{

finished = false;

int buffer = intArray[i];

intArray[i] = intArray[i + 1];

intArray[i + 1] = buffer;

}

runs++;

}

while (!finished);

string output = "";

for (int i = 0; i < intArray.Length - 1; i++)

{

output += intArray[i] + ", ";

}

output += intArray.Last();

return output;

}

public class ShuffleEnumeratorStrategy : IEnumerateStrategy
{
    public string Enumerate(int[] numbers)
    {
        Thread.Sleep(500);
        Random rnd = new Random();
        int[] randomised = numbers.OrderBy(x => rnd.Next()).ToArray();
        string output = "";
        for (int i = 0; i < randomised.Length - 1; i++)
        {
            output += randomised[i] + ", ";
        }
        output += randomised.Last();
        return output;
    }
}

public class ShuffleEnumeratorStrategy : IEnumerateStrategy

{

public string Enumerate(int[] numbers)

{

Thread.Sleep(500);

Random rnd = new Random();

int[] randomised = numbers.OrderBy(x => rnd.Next()).ToArray();

string output = "";

for (int i = 0; i < randomised.Length - 1; i++)

{

output += randomised[i] + ", ";

}

output += randomised.Last();

return output;

}

What could be done better in those three implementations is that part of the code that build output string is common so natural reaction would be to encapsulate it somehow, but please, turn a blind eye for that 🙂
Next step – writing our MagicBox class which has an array of 10 integer, randomly generated in the constructor, private field of type IEnumerateStrategy accompanied by a method for changing the strategy, and Display() method that writes numbers to the console using the strategy.

public class MagicBox
{
    public int[] Numbers = new int[10];
    private IEnumerateStrategy enumerator;

    public MagicBox(IEnumerateStrategy _enumerator)
    {
        Random rnd = new Random();
        for (int i = 0; i < 10; i++)
        {
            Numbers[i] = rnd.Next(100);
        }

        enumerator = _enumerator;
    }

    public void SetEnumerator(IEnumerateStrategy _enumerator)
    {
        enumerator = _enumerator;
    }

    public void Display()
    {
        Console.WriteLine(enumerator.Enumerate(Numbers));
    }
}

public class MagicBox

{

public int[] Numbers = new int[10];

private IEnumerateStrategy enumerator;

public MagicBox(IEnumerateStrategy _enumerator)

{

Random rnd = new Random();

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

{

Numbers[i] = rnd.Next(100);

}

enumerator = _enumerator;

}

public void SetEnumerator(IEnumerateStrategy _enumerator)

{

enumerator = _enumerator;

}

public void Display()

{

Console.WriteLine(enumerator.Enumerate(Numbers));

}

To test the example in application’s Main() method, we will create new MagicBox object and assign new AsIsEnumeratorStrategy, then invoke Display() method, and then assign some other available strategies and again invoke Display() method.

static void Main(string[] args)
{
    MagicBox box = new MagicBox(new AsIsEnumerateStrategy());
    box.Display();
    box.SetEnumerator(new SortedEnumerateStrategy());
    box.Display();
    box.SetEnumerator(new ShuffleEnumeratorStrategy());
    box.Display();
    box.Display();
    box.Display();
}

static void Main(string[] args)

{

MagicBox box = new MagicBox(new AsIsEnumerateStrategy());

box.Display();

box.SetEnumerator(new SortedEnumerateStrategy());

box.Display();

box.SetEnumerator(new ShuffleEnumeratorStrategy());

box.Display();

}

So, as a result we get number listed using three different strategies. Advantages of using Strategy Pattern is that you can write as many strategies as you want without changing the class that uses them and interchange them during run-time (the definition, right?).So that’s it when it comes to Strategy Pattern. If you’re interested in next pattern (which is going to be the Observer) please come back (probably) next week. Thanks!

Source code: download zip file