November 2017 - Michał Kajzer

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]