Design Patterns Series - Learn Design Patterns quickly

What is a design pattern?

From Wikipedia:

In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design.

I think that learning design patterns and the underline Object Oriented Design principles is really important. However, it is really difficult and time consuming. It requires a fair amount of discipline.

This is why I created this series of posts.

This post is a simple index that aggregates all the post I have written in the last two years. Most of the frequently used design patterns are covered but there are many others to cover.

I will update this post as soon as I create a post on a new Design Pattern.

My goals for this series of posts

• Read a lot of resources and consolidate the information in a single post
• Present the pattern in a easy way
• Write a good example to illustrate the benefits of using the pattern
• Put the pattern in the context of .NET
• Find real examples of the pattern in the .NET Framework

My main sources of information

• Book: Design Patterns: Elements of Reusable Object-Oriented Software
• Book: Head First Design Patterns
• Book: C# 3.0 Design Patterns
• Pluralsight: Design Pattern Library
• Articles and blogs on the Internet

 Design Patterns Posts

• Strategy Design Pattern
• Observer Design Pattern
• Decorator Design Pattern
• Factory Method Design Pattern 
• Abstract Factory Design Pattern
• Singleton Design Pattern
• Command Design Pattern
• Adapter Design Pattern
• Facade Design Pattern
• Template Method Design Pattern
• Iterator Design Pattern
• Builder Design Pattern
• Prototype Design Pattern
• Bridge Design Pattern
• Composite Design Pattern
• Flyweight Design Pattern
• Proxy Design Pattern
• Chain of Responsibility Design Pattern
• Interpreter Design Pattern
• Mediator Design Pattern
• Memento Design Pattern
• State Design Pattern
• Visitor Design Pattern

Hope you find this series of posts useful.

The Iterator Pattern in .NET

The Iterator Pattern provides a way to access the elements of an aggregate object (collection) sequentially without exposing its underling representation.

The ultimate goal of the pattern is to decouple the client from the implementation of the collection that always remains well encapsulated.

This is definitely my favourite pattern in particular for how it is supported by C#.

It's easy, amazing and extremely powerful.

The Client

In the .NET framework the pattern is fully supported by all the collections in the Base Class Library and the C# language provides the foreach keyword to iterate a collection in an extremely simple way. Every .NET developer knows it.

What is the beauty of the pattern?

The beauty is that the client does not need to know nothing about the internals of the collection in order to iterate through its elements. Replacing the List with an HashSet does not require to change the foreach loop in any way.

How does it works?

The foreach loop works only on collections that implement the interface IEnumerable or the generic version IEnumerable<T>.

All the .NET framework collections implement that interfaces included List and HashSet.

The IEnumerable interface contains a factory method that should return an implementation of the interface IEnumerator or the generic IEnumerator<T>.

An enumerator class is responsible to enumerate the collection. It is a read-only, forward-only cursor over a collection.

The property Current returns the current element in the collection; the method MoveNext() advances the enumerator to the next element of the collection; the method Reset() sets the enumerator to its initial position, which is before the first element in the collection.

Everything becomes clear when you see how the C# compiler translates the foreach loop using directly the enumerator. This is the magic!

Using a .NET disassembler like ILSpy or dotPeek however we can't see the translated version in C#. In order to have a confirmation that what I said is actually true we have to look directly at the generated IL.

It is easy to see that the compiler actually does something more. It wraps the enumeration in a try/finally construct in order to properly Dispose the enumerator. This is important because IEnumerator implements IDisposable.

Finally, this is the correct C# version of foreach.

The foreach statement simply provides a very elegant way to generically enumerate a collection.

How to Implement Enumerable Collections

OK, brilliant,we now know how to enumerate any collection using the foreach keyword and in particular how this is actually done under the cover.

It's time to create a custom collection. For example, a collection that is able to store any integer between 0 and N using internally a frequency array. This is actually pretty simple to do.

However, the following code does not compile. The compiler is not able to initialize and enumerate the collection.

We obviously need to implement the IEnumerable interface

A typical choice is to use a nested type to implement the enumerator. This allows to access the internal of the collection to accomplish the job. Note that the enumerator is intrinsically coupled to the collection. It turns out that implementing an enumerator it is not so easy as it may seems initially.

The complexity of implementing the enumerator arises because it is required to maintain the current state of the iteration between subsequent calls to MoveNext. In the example the variables pos and count are required in order to maintain the state of the iteration.

Can you understand the code inside MoveNext?

Yes, I know. You may understand it but it is definitely not intuitive.

Fortunately, the C# compiler comes in help here with the keyword yield that implements the concept of coroutines in .NET.

You can implement all in the following beautiful way without the need to manually implement the enumerator yourself.

This looks like really magical!

But we are curious, let's deep dive and see the code generated by the compiler.

OK, the compiler create an instance of a compiler generated enumerator class passing through a property a reference to the collection. The compiler generated enumerator is also a nested collection.

The compiler generates a state machine under the cover. It is really impressive what it does but all this complexity is hidden to the developer thank to the yield keyword.

The Iterator Pattern and LINQ to Objects

Everything we discussed so far has always been available since C# 2.0.

C# 3.0 added LINQ to the language expanding in a significant way the potential of the language. This is without any doubts the main reason why I love C#.

The power of LINQ to Objects in particular is related to the fact that iterators are highly composable.

Consider the code that print the double of the even numbers from the collection using LINQ to Objects.

How the enumeration process works in this case?

The first call to Where generate a enumerable object that wraps the source collection using the decorator pattern. The object itself however is also the enumerator of itself. The main logic is inside the MoveNext method that iterates the source collection and then apply the filter.

The same is for the Select method where the source collection in this case will be the result returned by the Where method.

The execution at run-time will be a chain of enumerations that is simply described by the following sequence diagram.

Conclusion

The iterator pattern these days is a fundamental pattern and it is fully integrated in the modern programming languages and libraries. In particular in C# you can leverage the pattern using the foreach statement in the client code, and implementing IEnumerable and IEnumerator when you create new collections. Don't forget the incredible support that the yield keyword can provide you when you implement your custom collections.

It's important to notice that the iterator pattern is a good example of the Single Responsibility Principle: "A class should have only on reason to change". The Enumerator class is a class with the single responsibility to traverse a collection.

The main benefit of the pattern is decoupling the clients from the internals of the collections. This allows to change the collection without affecting clients.

The Template Method Pattern in .NET

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.

This pattern is typically used to implement frameworks as an important technique for code reuse. It allows to encapsulate pieces of algorithms so that subclasses can hook themselves right into a computation.

You can use this pattern when you recognize that two or more algorithms are similar except that some of the steps require different implementations.

General procedure to follow:

• Create a class (abstract if you want mandatory steps)
• Create a generalized version of the algorithm in a method or more (possibly sealed)
• Use protected abstract methods when a step of the algorithm is required
• Use protected virtual methods when a step is optional
• If needed, add a default implementation for optional steps
• Create a subclass for each specific algorithm implementing all the various steps

It is quite easy to create a simple example of the pattern but I think that is much more useful to identify implementation of the pattern in your favourite frameworks. This pattern is used in almost every framework.

Example: The XNA Framework

The XNA Framework extensively use the Template Method Pattern to provide a base class Game that encapsulates the common algorithms of a game. Each subclass of the Game class implement a specific game reusing lots of the code defined in the baseclass.

If you look at the documentation of the Game class on MSDN you can see that there a lot of protected virtual methods. Each of this method can be seen as a step of the "generic game" algorithm.

Let's consider the two more important hooks:

• Update()
• Draw() 

Using a .NET Disassembler you can easily look inside the Game class and identify the template methods.

You can see that the Game class provides a default implementation of Update() and Draw() methods.

As a consumer of the framework the only thing you need to do is to override Update() and Draw() and the base class will take care of all the aspects of the game.

It is important to notice that clients can call or not the base class method with the default implementation. This can cause subtle bugs that can be hard to find and can be seen as a drawbacks of the pattern. As a framework implementer you should avoid this situation if you can, otherwise is important to document well what a client should do.

Example: Event Handling in .NET libraries

The entire .NET framework uses the Template Method Pattern extensively to provide internal clients with a simplified way to handle events.

Microsoft recommends using a protected virtual method for raising each event. This provides a way for subclasses to handle the event using an override.

You can see an example of this pattern in the ASP.NET Control class.

An internal client can override the method and add custom logic to it. Note that the Page class inherit indirectly from the Control class.

Having a default implementation makes the client asking the following questions:

• Should I call the base method?
• Should I write my custom code before calling the base method?
• Should I write my custom code after calling the base method?

There is not a generic answer to this questions because it always depends by the framework and how the base method is implemented. This should clearly be documented because it can be the source of many problems.

A way to avoid all of this problems is to use abstract methods. However, adding too many abstract methods can make the framework difficult to use because the client is forced to override all the methods even if it is not necessary.

Finding the right trade-off is surely not something easy to do.

Microsoft says on this:

The derived class can choose not to call the base class during the processing of OnEventName. Be prepared for this by not including any processing in the OnEventName method that is required for the base class to work correctly.

This problem is strictly related to the Liskov substitution principle. Not calling the base class can violate the principle.

Design Principles and Limitations

It is possible to continue forever with examples from the .NET Framework but I think that you got the idea behind the pattern.

The object oriented design principles used by the pattern are:

• "The Hollywood Principle": Don't call us, we'll call you.
• The Open/Close principle

The main benefits of the pattern is:

• Code reuse (subclasses implement only the behaviour that can vary)

There are however some limitations in using this pattern.

The first limitation is that the pattern rely on inheritance. A way to avoid inheritance and achieve a similar goal is to use the Strategy Pattern.

The second limitation is that inheritance makes difficult to merge two child algorithms into one. In that situation, the Decorator Pattern can be a solution.

The Facade Pattern in .NET

The Facade Pattern provides a unified interface to a set of interfaces in a subsystem. Facade defines a higher level interface that makes the subsystem easier to use.

The Facade Pattern is the simplest of the patterns and it is something that many developers probably used a lot in the past without even knowing that there was a name for it. 

It is all about creating a class that simplifies and unifies a set of more complex classes that belong to some subsystem. However a Facade typically does not hide the complex subsystem but simply provide a different simplified view of it. This means that is always possible to use the complex subsystem when needed and that is theoretically possible to have multiple Facades per subsystem.

This pattern typically use the technique of "wrapping" to accomplish the goal. It is important however to remember that the intent of the pattern is to reduce complexity and not to adapt different interfaces like the Adapter Pattern.

I think that it is not worth creating an artificial example to showcase the Facade Pattern. It is more valuable to show examples of usage in the .NET Framework.

A primitive way to implement a Facade is using a static class.

The most significant example in .NET is surely the class File that provide a simple way to interact with the file system in a very intuitive way instead of using lower level abstractions like streams.

This method hides a lot of complexity. If you look inside the .NET Framework source code you find something similar to this:

An another example of Facade in the framework is the class WebClient that allows to easily download a web page from a server without dealing with the HTTP protocol and the sockets.

The beauty of the pattern is then in its simplicity and obviousness.

In addition of simplifying the access to a subsystem the pattern allows to decouple your client implementation from the subsystem. If future version of the subsystem changes the internal components this will not require to update the client code assuming that the Facade API remains unchanged.

The Adapter Pattern in .NET

The Adapter Pattern converts the interface of a class into another interface the clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.

The pattern is also called "Wrapper" because it is usually implemented using the technique of wrapping objects (object composition).

There are different situation when the pattern can be useful but a typical scenario is when you create an abstraction above code that is likely to change in the future. In this way, instead of changing the client code in the future the only thing to do will be implementing a particular adapter.

Let's see immediately an example.

Instead of defining an abstraction myself, I decided to base my example on the  DbDataAdapter class available in the .NET Framework that defines an abstraction for data access operations. 

Suppose we have a simple application that print the list of all the customers extracted from a local SQL server database.

This is an example of execution:

Suppose that a new vendor release a special file based database with the following code.

Assume the following new requirement:

• Use the new file database instead of SQL Server

It is obvious that the FileDb interface is completely different and incompatible with the interface expected by the client application.

What do you do?

You can use the Adapter Pattern!

In particular, you can create a specific DbDataAdapter class.

Of course you need to migrate the data from SQL Server to the file database:

The beauty of the pattern is that you don't need to change the client code. The only thing that you need to do is to simply use the new FileDbDataAdapter.

All the changes to implement the requirement are encapsulated in a single class: FileDbDataAdapter. 

The designer of the application created the adapter abstraction since the beginning because he was aware that changes of the data access code are highly likely in the future. If this abstraction was not created the change would have been more intrusive that this.

Most of the applications using third party libraries use adapters as a middle layer between the application and the library itself to decouple the application from the library. If another library has to be used only an adapter for the new library is required without having to change the application code.

The main Object Oriented Principles used by the Adapter Pattern are the following:

• Favor composition over inheritance
• Encapsulate what varies
• Program to interfaces, not implementation
• Open/Closed principle

The Command Pattern in .NET

The Command Pattern encapsulates a request as an object, thereby letting you parameterize other objects with different requests, queue or log requests, and support undoable operations.

The formal definition of the pattern is quite general and it shows how the pattern is versatile and can be used in many scenarios but the real important thing however is the first sentence, the idea that you can define a command in order to encapsulate a request to do something and use that command as a normal object. 

The Command Pattern allows you to encapsulate a method invocation.

The biggest benefit is separating the object making requests from the objects that receive and execute the requests. 

In order to describe the pattern I will implement a very simple transactional installer.

Let's assume we have the following requirements:

1. The installer allows you to execute an operation
2. The installer is independent by the specific operation executed
3. The installer is able to roll back an operation in case of errors
4. The installer is able to execute multiple operations as a transaction that is if something goes wrong all previously executed operations will be rolled back

The Command Pattern is the best way to solve this problem.

Let's start to define the command abstraction:

We can easily satisfy the first three requirements defining an installer that accept an instance of the command and calls its methods when requested.

As you can see, the Installer class is completely independent by the specific command that is provided in its constructor. In the same way, the command itself is also completely independent by the Installer.

You can define as many commands as you want:

You can easily create a program to execute some operations:

Super easy isn't it?

What about supporting transactions?

It is here that the real beauty of the pattern comes  in. Because you treat a  command as a normal object, you can aggregate them. Nobody stops you to define a kind of Meta Command that aggregate lots of commands together and in addition implement the support for transactions.

Consider that the TransactionInstallerCommand is still a command. This means that you can use the Installer class without any changes to run a set of commands in a transactional way.

Let's see an example of usage.

Is it not amazing?

In order to simulate an error I created a special command that throws an exception all the time is called.

This is the output of the program:

This example and the Command Pattern is a demonstration of many Object Oriented Principles

Encapsulate what varies

The implementation and the number of each operation is what varies and we encapsulated this creating the CommandInstaller abstraction.

Favor composition over inheritance

The Installer use a Command using composition. The same does the transaction command that compose many commands together in order to create an extremely flexible command.

Program to interfaces not implementations

Depend on abstractions. Don't depend on concrete classes

Strive for loosely coupled designs between objects that interact

InstallerCommand is the main interface introduced here that allows a very loosely coupled design with the Installer.

Classes should be open for extension but closed for modifications

It is very easy to create a new command and you don't need to change the TransactionInstallerCommand in order to use it. TransactionInstallerCommand satisfy the Open/Closed principle.

We didn't finish yet because I am sure you have a question.

In .NET we have delegates and lambda as a way to represent code as an object. At the end of the day, this is what the command pattern is about or not?

This is absolutely true!

.NET developers are now quite familiar with code like this:

If you think carefully the Where method is accepting a command as an input and it is independent by the specific command provided. In this case the command is a predicate that is a function that takes an argument and returns a boolean as the result.

In addition, the predicate requested is just a specific instance of the generic delegate called Func defined as follow:

This Func object is actually the declaration of a generic command.

How would you implement a method similar to Where without having delegates?

Using the Command Pattern of course!

Let's try to do this.

This is an example of usage:

What is wrong about this?

Nothing! However you can easily agree with me that the solution using lambda has a big advantage: you don't need to create a new class all the times you need a new command. 

LINQ has been introduced in the language starting from the version 3.0 of C# and is the biggest implementation in the entire framework of the command pattern using lambdas.

LINQ together with some new features made the C# a better language enabling  some of the most useful features available in so called functional languages.