One of the quirks of extension methods added to the .NET 3.5 release is that you can add them to interfaces; seemingly adding implementation to interfaces. By definition, in the CLR (and most other languages or platforms) interfaces contain only the signatures of methods, delegates, properties or indexers. By implementing an interface in a class, the body of the method, delegate, property or indexer is added…the implementation is added.

For example:

Here I am extending the IMessage interface with a couple of methods for simplifying access to value pairs contained within a IPrimitiveMap (a hash map implementation). A couple of unit tests illustrates the usage:

Truthfully, you are truly adding nothing the interface! No implementation is actually added…basically a static class is created with the extension methods and some compile time kung fu enables you to invoke the method off of the interface definition. Extension methods are not of the domain of the CLR, they are of the domain of the compiler via the System.Runtime.CompilerServices.ExtensionAttribute.

I would imagine this is old news for most seasoned .NET developers, but I just kind of stumbled upon it myself today and thought it was interesting with respect to interfaces and implementation :)

Background

As part of an automated process I have a service that recursively iterates through an FTP directory and pulls down any new or changed files saving them to disk before being uploaded into a CDN (Content delivery network) where they are used on the Web. Another automated process digitalizes published magazines and writes the images and text as XML documents into this FTP directory (so it can be consumed).

This has been running for some time when I noticed that there were a lot of images that were not being copied down from the FTP server. After some investigation I noticed that the only images with spaces in the name were failing to download and upon looking into my code it was pretty clear what was going wrong.

Processing the LIST Command Result

I was using the WebRequestMethods.Ftp.ListDirectoryDetails flag which makes the FtpWebRequest object use the FTP LIST command to retrieve the file names in each directory. The FTP server is a Unix based computer thus when I execute the directory LIST command it returns back a CLRF delimited blob of text containing a record describing each file in the directory as a record that looks like the following:

This breaks down into the following structure which is delimited by a space:

mode

links

owner

group

size

datetime

name

-rw-r--r--

1

1089

1091

505482

Nov 19 22:53

paper texture 2jpg1290206009609589.JPG

Note that there is another FTP command NLIST, which returns back just the filename itself which works just fine, but it doesn’t given you enough information about what kind of entry the file is. For example, if I encounter a folder, I want to step into and read the contents. If it’s a file, I want to download the file. The mode portion of the LIST result gives you the information required to make this is decision: if the first element is a “d”, it’s a directory so keep traversing…otherwise assume it’s a file so download it.

The Problem with Spaces (and my code)

When I process a LIST record string, I split it into an array and based on ordinal (position-the last element) I select the name element:

The problem is that when the name element has spaces, the last element is the last whole part of the file name – any proceeding parts are split into separate elements and ignored. So for most files, there were no problems; it wasn’t until files with spaces in the name began appearing did the appear.

Regular Expressions To The Rescue

A quick Google search revealed that people who have encountered this problem, used regex’s to correctly parse the LIST result record. In particular, this post on stackoverflow hit the nail on the head:

Lazy initialization or lazy loading, is the idea that the object will not be constructed, created, initialized or loaded until it is absolutely needed. A common scenario for lazy initialization is a list that stored in a cache is empty until it is accessed, then it is loaded perhaps from a record-set in a database or file and then placed into cached and finally returned back to the caller. If the list is never requested, then the cache is never filled and the application’s working set is smaller. Typically smaller working sets (of memory) mean better perceived performance and happier customers.

System.Lazy<T> provides a (potentially) thread safe wrapper around an object and provides a means of deferring initialization of the core object until it’s requested via Func<T> delegate. Depending upon the constructor called, you can emulate one or more different locking techniques such as doubled checked locking, using a nested class to defer initialization or by doing initialization via a locking mechanism when the object is first accessed. In memory challenged situations, the System.Threading.LazyInitializer class provides static methods for doing thread-safe (potentially) lazy initialization as well.

I included thread safety “potentially” in parenthesis above because depending upon the constructor overload or method overload used on Lazy<T> thread safety may or may not be ensured. The reason this is so is to improve performance when thread safety is not required or desired because no synchronization locking is done.

Lazy Initialized Singletons

One of the commonest examples of lazy initialization are implementations of the GOF pattern, the Singleton. There are several ways to implement the singleton pattern in C# using lazy initialization, from extremely simple to somewhat complex. Each way offers differences in thread synchronization schematics used, the relative thread safety, and the “laziness” of the implementation. Besides the traditional way of implementing singletons, you can also use one of the new .NET 4 classes System.Lazy<T> or System.Threading.LazyInitializer class.

Their are at least four thread-safe variants of the singleton available to languages targeting the CLR with three of them supporting directly lazy initialization. In a nutshell they are the double-checked locking techniquewhich is broken in Java, but works accurately in C# [1], and full lazy instantiation using a nested inner class with a private static constructor and a reference to an internal static readonly instance of the parent class, and a third version shows thread safe lazy initialization with the caveat of reduced performance since a lock is acquired on all reads. For an in-depth discussion check out Jon Skeet’s excellent article on the topic.

Using the System.Lazy<T> class in .NET 4.0 you can easily implement the singleton pattern in a thread safe, lazy initialized manner that is optimized for performance:

Note that passing in “true” to the constructor makes the initialization thread safe by using double locked schematics described above. If “false” is passed in for isThreadSafe, then no synchronization takes place. You can also use one of the following LazyThreadSafetyMode enumerations in another overloaded constructor call:

LazyThreadSafetyMode.ExecutionAndPublication – uses the C# lock keyword which the CLR interprets as a Monitor (note in Richter’s book he states that it uses double checked locking, but reflector shows only one lock…)

Here is another example using System.Threading.LazyInitializer:

Lazy Initialization and Micro Optimizations

Now one might argue that lazy initialization is a premature if not unnecessary micro-optimization. In some respects that is probably true. Singletons, for instance, are only created once for the entire lifetime of an application, typically at start up. However, if you truly need thread safety, lazy initialization then System.Lazy or System.Threading.LazyInitializer are the way to go with .NET 4.

C# allows method group conversions, which simplify the invocation of delegates within your code. This is a feature that was added to C# 2.0 and when combined with the Linq extensions provided with .NET 3.5, you can drastically shorten and simplify code.

“Similar to the implicit anonymous method conversions described in §13.5, an implicit conversion exists from a method group (§14.1) to a compatible delegate type. If D is a delegate type, and E is an expression that is classified as a method group, then D is compatible with E if and only if E contains at least one method that is applicable in its normal form (§14.4.2.1) to any argument list (§14.4.1) having types and modifiers matching the parameter types and modifiers of D.”

Basically what the above means that the compiler is “smart” enough to infer the correct overload to call given that their is an adequate candidate method available. For example, given the following two methods:

First we can refactor the for loop using lambda expression and the Linq extensions:

Then simplify the lambda expression even further by substituting for the implicit method group conversion:

Note that the green squiggly lines are hints made by Resharper that the line of code can be refactored. If your not aware of Resharper, it’s a Visual Studio add on that turns VS from a Pinto to Ferrari! If you don’t believe me, try the free trial here. Ok, enough cool-aid and free marketing for resharper…

So, your probably thinking one of three things about now (assuming you made it this far):

“Big fricken deal, he saved five lines of code”

“Eh, old news. Moving on.”

“Wow, that’s fricken awesome dude!”

Personally, I tend towards #3. I am a huge fan (obviously) of method group conversions because they reduce complexity. They simply make the code easier to read and digest. Code that is easier to read and digest is more easily maintained. Code that is easier to maintained, tends to be of higher quality and less error prone.