Category Archives for "Design Patterns"

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


 Design Patterns Posts

Hope you find this series of posts useful.

5 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 only works on collections that implement the interface IEnumerable or the generic version IEnumerable<T> (NOTE: this is not entirely true as pointed out by Philip Kendall, for more info see https://msdn.microsoft.com/en-us/library/9yb8xew9.aspx).

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

 

6 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.

 

2 The Singleton Pattern in .NET – If you can avoid it

The Singleton Pattern ensures a class has only one instance, and provides a global point of access to it.
NOTE: This pattern is now considered by many (included the creators) an anti pattern and it is presented only for completeness! Read why.
A Singleton is a class that manages a single instance of itself and prevent any other class from creating a new instance on its own. The only way to get the instance is passing through the Singleton class itself. 
 
Singletons are frequently used to provide a global access point for some service.
 
Let’s see an example of Singleton that implement a trivial logging service.
 
 
and an example of usage:
OK but… what are the advantages?
As we said in the definition of the pattern, the main advantages are:
  • Making sure that there is a single instance of the service. This is accomplished making the constructor private and the class sealed.
  • Providing a global point of access to that instance.
Mmm but I can solve the same problem writing the following code, right?
It is true!
However, there are still some advantages in using the Singleton approach:
  • You don’t have to put the static keyword everywhere
  • You can use singletons as parameters or objects
  • You can implement singleton with interfaces
  • You can write tests even if this is not simple
Anyway, singletons have more problems than benefits and these days many developers tend to avoid it if they can.
The biggest problem is the fact that you can use singletons where you want (they are like global variables) and dependencies are hidden inside the client objects. This means that the interface of the client objects don’t reveals all the dependencies and this make testing very hard. In addition, in order to be able to write the tests you have to create a mechanism to replace singletons with mocks (a static Initialize method for example) that in some way violates the definition of singleton itself.
These days there are better ways to solve this problem and they usually involve other patterns like Service Locator and Dependency Injection. I will describe these patterns in later posts.

Abstract Factory Pattern in .NET

The Abstract Factory Pattern provides an interface for creating families of related or dependent objects without specifying their concrete classes.
In a previous post, I have shown that in the Factory Method Pattern the object creation is done through inheritance. Instead, the Abstract Factory use object composition. Object creation is implemented in methods exposed in the factory interface.
Wait a moment please… you are going too quick!
What is the advantage? Can you show an example?
The advantage is the same like other factory patterns, that is, decoupling clients from any of the specifics of the concrete classes. They all promote loose coupling by reducing the dependency of your application on concrete classes. Abstract factory in addition allows you to group together a set of related classes and provides a consistent usage to clients. It is a kind of evolution of the Factory Method pattern.
Let’s see an example.
Instead of starting from the implementation, I would like to start from the client. I believe that it is easier to understand the value of the pattern in this way. 
We want to provide security services (signing and ciphering), in an application and we want the ability to easily change the level of security provided. 
Look carefully at the client code.
As you can see, the client always rely on abstractions. AbstractSecurityFactory is used by the client to get a pair of related objects: the signer and the cypher. However, the client is completely unaware of the specific classes involved. 
The specific factory (that defines the level of security) is usually defined in some configuration and the GetSecurityFactoryFromConfiguration method simulate this.  
In the example, we are using a normal security level in our application. 
How can I change the security level of my client application?
Simply change the concrete factory! All the other client code remains the same.
Here, we disable the security in the application:
OK, let jump in the implementation.
Let’s start with our abstractions:
There is an additional abstraction that is used for convenience in the internals. 
This is the family of classes that represents the absence of security.
This is the family of classes that represents the normal level of security using the algorithms SHA256 for signing and DES for encryption.

I don’t want to be tedious and create a set of classes to implement an high level of security. I am sure that you can easily guess it!
You learnt that the abstract factory pattern should be used whenever you have families of products you need to create and you want to make sure your clients created products that belong together.
One of the best example of use of the Abstract Factory Pattern in the .NET Framework is in ADO.NET. There is a class called DbProviderFactory that is an abstract factory and provides clients the ability to create a set of objects designed together to communicate using a specific technology or with a specific database product like ODBC, OleDb, SQL Server and so on.
This is a reduced class diagram that shows some classes involved. 
In this example, the products are all the objects required to communicate with a database: Command, Connection, CommandBuilder, ConnectionStringBuilder, DataAdapter and so on.
Let’s have a look of an example of usage of this class.
The beauty of this pattern is that you write the code of your client in a way that is completely independent by the concrete implementation (in this case by the specific database) and this allows you to change the concrete implementation in a very easy way.
Once again, the foundation Object Oriented Design principle related to this pattern is the Dependency Inversion Principle that is worth to remember in the following two definitions.
Depend upon abstractions. Do not depend upon concrete classes.
High-level components should not depend on low-level components; rather, they should both depend on abstractions.

Factory Method Pattern in .NET

There is a little bit of confusion around this pattern because Factory Method can be implemented in many different ways but I want to stick with the original definition of the pattern.
The Factory Method Pattern defines an interface for creating an object, but lets subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.
This pattern can be used by frameworks to delegate the creation of a specific concrete class at the extern of it in order to provide higher flexibility for their clients. The framework will provide logic using abstract classes or interfaces delegating to clients the responsibility to provide concrete implementations.
Suppose we want to create a very simple framework for a video library that provides a basic system to buy movies. However, because the policies about prices and permissions varies, the framework leave the clients the responsibility to create  the specific policies.
Therefore, the framework defines an abstract class VideoLibrary that implements the buy operation:
As you can see, this class is abstract and the method GetPolicy is a Factory Method. It is responsibility of the client to create a subclass of VideoLibrary and return the appropriate policy. The framework simply define the IPolicy interface and the Customer and Book classes.
Let’s write a client that use our video library framework defining the following policies:
  • Children can’t buy porn and horror movies
  • Children always have a 50% discount
  • Adults can buy any movies
  • Adults pay the full price
  • A child is a person with age lower then 18
This is the code:

 

 

 

This is an example of usage:
with the relative output:
This patterns provides a way to decouple the implementation of a class (IPolicy) from its use (in VideoLibrary). This is the flexibility that this pattern offers to clients.
The Object Oriented Design principle to keep in mind in this case is the following:
Depend upon abstractions. Do not depend upon concrete classes.
This principle is often called Dependency Inversion Principle.
In our example, the video library framework defines the abstraction IPolicy and does not depends upon concrete implementations. It demands to clients this responsibility and this is accomplished using inheritance.
A different way to describe the principle is:
High-level components should not depend on low-level components; rather, they should both depend on abstractions.
In our example, the high-level component is the VideoLibrary class while the low-level components are the implementations of the IPolicy interface. The IPolicy interface is the abstraction that has been created in order to invert the dependency.

4 Decorator Pattern – Streams in .NET

The Decorator Pattern allows to attach additional responsibilities to an object dynamically. It is an alternative to subclassing for extending behaviour.
Instead of creating a silly example of usage I decided to rely on one of the best example of implementation that is already available in the .NET Framework: the Streams.
The following class diagram is a restricted view of the Streams hierarchy in .NET:
Recognising the pattern is usually quite simple. When you see an object that inherit from a base class (Stream) and at the same time has a constructor that accept an element of the same base class (Stream), you probably came across to a Decorator.
The idea is that you can create an object that wraps an another object (of the same type) in order to provide new functionalities and the resulting object can be wrapped again creating a chain of objects that together provide a combination of functionalities. The beauty is that any single object is unaware that it is wrapped and this allows to create any combinations of them at runtime. If you consider the alternative of creating a single class for each combination of functionalities, the flexibility you get with the Decorator pattern is immense.
In the previous diagram there are three Decorators:
  • BufferedStream
  • CryptoStream
  • GZipStream
But what about the others classes?
FileStream, MemoryStream, NetworkStream does not have a constructor that takes a Stream. They simply are Components and not Decorators. This means that these objects can only be wrapped and cannot wrap other objects. These objects represent the end of the chain.
Yes, it seems quite complicated but it is not. Let’s make a concrete example.
Problem
Create a TCP client that allows you to send a message over the network to a TCP server. Before sending, the message will be buffered, compressed and then ciphered. The server will do the opposite operations in order to receive the message correctly.

Streams represents the best way to implement this scenario.

Solution

This is the code that creates a TCP client and send the message over the network:
From the example, it should be easy to figure out how the wrapping process works. Wrapping is the way to add functionality in a dynamic way. If you don’t want to compress the data, you can simply remove the gzipStream wrapper. In addition, you can also change the order in which you want to execute the operations, simply wrapping in a different order. The decorator pattern provides you this flexibility.
The server side code is symmetric except that I decided to write the output to a file instead, using a FileStream.
Just for completeness this is the entry point of the program:
When you run the program the client send the message, the server receives and saves the message in a file that will be opened at the end.

The main Object Oriented Design principle respected by the decorator pattern is the Open/Close Principle.

Software entities should be open for extension, but closed for modification.
What? How can you extend the system without changing it?
You can create a completely new class that inherit from Stream and add it into the chain in any position you want.
 
The streams hierarchy provided by .NET is open for extension but you don’t need to change the code of the framework to do this (it is closed for modification).

Source Code:
Decorator Pattern – Streams in .NET

 

1 2
>