Sunday, 10 February 2013

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.

Wednesday, 6 February 2013

The Rapid Growth of DotNetToscana

I am absolutely impressed by the rapid growth of the .NET community in Tuscany that I contributed to found in 2008. At the time, we were three passionate people with the dream to create a community of developers around the Microsoft .NET technologies with the ultimate goals of learning together by sharing knowledge and experience.

This quick interview has been taken by the Microsoft Developer Evangelist, Pietro Brambati in Florence the day we launched the community at the Microsoft Days 2008 Conference.


In 2013 we are now the Official Microsoft Community in Tuscany part of the new Microsoft Technical Communities program.

I would like to thank you all the members of the staff for the great technical skills and impressive enthusiasm they bring everyday to the community. In addition, all of them, are people I can call "friends" and this is an additional value of doing community.

This is the full list of people that are currently part of the staff:

We also have an official polo shirt...


...and many many sponsors:


This is the list of events we delivered in 2012. I would say awesome!


In conclusion, I would like to thanks all the people that attended our events. Without them DotNetToscana couldn't be what it is now. Thank you!

More info on the official website: http://www.dotnettoscana.org

We often write in English. You can find us in all the major social networks:


I wish all the best for for the community and surely I will continue to give my little contribution to its future success.

Sunday, 3 February 2013

Conditional Attribute in C#

Conditional directives in C# are extremely useful to include or exclude regions of code from compilation. This allows you to target different platforms.


Consider a class Logger with a Log method. If you want to log a message only in debug mode you could do something like this.


This code is ugly isn't it?

This is an another way to do it but it is not exactly what we would like. The code works but there are lots of useless function calls that reduce the performance at run time.

This is the situation when the Conditional attribute is useful. The following code is equivalent to the first example but much more readable.

This attribute is in fact extensively used in the classes Debug and Trace.

The next time you use conditional directives, keep in mind the Conditional attribute.

Unsafe and Fixed keywords in C#

C# allows you to manage memory directly when needed mainly for performance reasons.

In order to do so you need to compile your code using the /unsafe switch. This is required because unsafe code cannot be verified by the CLR.

In Visual Studio you can enable this in the Properties panel.


In this post I would like to run a simple experiment to measure the difference in performance when you run a very simple matrix filter: computes the square of each number in the matrix.

The safe method:
The unsafe method:
The unsafe keyword denote that the method contains unsafe code. The keyword fixed is required to pin a managed object (matrix in this case) in order to avoid that the garbage collector move the object while we perform the operation.

Inside an unsafe block it is possible to use pointers in C#. Surprised?

This is the code that compares the performance of the two versions:


The output is the following:

Safe time: 0.4410526
Unsafe time: 0.1252171
Unsafe is 3.52230326369162 times faster


There is a lot to say about unsafe in C# but I don't want to go deep in the subject because the use of pointers is almost never required and it should be avoided if possible.

The important lessons from this post are:

  • C# allows to use pointers and manage the memory directly if you need it
  • Unsafe code in C# can improve performance
  • Always measure performances to justify the use of unsafe code