Extension Methods - My new best friend*

No that doesn't mean that I'm going to be [ab]using extension methods everywhere - though I suspect that extension methods could become the new singleton. That said I think that I am really starting to get them. Here's an example.

Last night I'm doing some coding and I want to get some objects that I have written to serialise nicely to Xml. Now I don't want to give them public constructors as they sit within an aggregate, and should only be constructed by the Factory for that aggregate. Also I want to exercise quite a lot of control over the XML that is written. This being the case the use of the XmlSerializer class is pretty much unacceptable to me (see, it's not just because I resent spelling it with a 'z').

Now, pre C# 3.0 I would normally have a method in a helper class somewhere with a method that looked a bit like this.

public static XmlAttribute CreateAttribute(XmlDocument xmlDocument, string name, string value)
{
XmlAttribute newAttribute = xmlDocument.CreateAttribute(name);
newAttribute.Value = value;
return newAttribute;
}

Leaving aside that Helper classes offend me somewhat (if you want to know why then read this book). It would be much nicer if the XmlElement class just had an AppendAttribute method with the suitable overloads which would both create the attribute for me and append it to the element. Well, thanks to the power of extension methods this is very easy to do. Just look at the code below.

public static void AppendAttribute(this System.Xml.XmlElement xmlElement, string name, string value)
{
XmlAttribute newAttribute = xmlElement.OwnerDocument.CreateAttribute(name);
newAttribute.Value = value;
xmlElement.Attributes.Append(newAttribute);
}

public static void AppendAttribute(this System.Xml.XmlElement xmlElement, string prefix, string localName, string namespaceURI, string value)
{
XmlAttribute newAttribute = xmlElement.OwnerDocument.CreateAttribute(prefix, localName, namespaceURI);
newAttribute.Value = value;
xmlElement.Attributes.Append(newAttribute);
}

With this I now just have to make this single, easy, call when I want to add an attribute to an element:

newElement.AppendAttribute("id", _id);

Nice, eh!

* Girlfriend excluded

The Price of .Net's Diversity

.Net, since its' inception, has always tried to be a friend to everyone. A truly general purpose set of software development technologies. It offer both RAD and enterprise level development tools, dynamic languages, functional languages, type-safe languages, and OOP languages. With the Entity framework, Astoria, the DLR, dynamic data, and more shortly on the way the incredible breadth of the .Net offerings just continues to expand - and that's without even mentioning any of the open source technologies.

But whilst with this incredible diversity we gain a lot of flexibility we have to pay a heavy price. Perhaps the biggest cost is the discipline we must exercise when we approach problems. .Net makes it very easy, and even seem rewarding, to do things badly.

Whilst something like Ruby on Rails makes it difficult to work following patterns and practices which are not standard in its community. .Net at best does little to encourage what are generally considered good practices (separation of concerns, low coupling, explicit intent, unit testing, etc...), and at worst encourages bad practice.

Take the provider mechanism introduced in ASP.NET 2.0. Yes this makes it quick to bind a data grid to a data source, but the moment that you need to do something beyond a demo app it start to lose its shine and make life difficult. Unfortunately a lot of developers struggle on anyway and concerns that ought to belong to a data or repository layer are placed in the markup of an aspx page. Yes there is an object provider, and as CLSA.NET does, this can be usefully put to work.

Another example is the dataset, invidious things that seem to be an overt attempt to subvert OOP, AOP, or any other good practices.

I could list many more examples. Often these things are a fools gold that promise much but deliver nothing. They lead to more code being written. They make unit testing at best very difficult, and often impossible. They inhibit changes in functionality. They make maintenance and code handovers very taxing.

But what concerns me almost more is that they seem to breed 'wrong thinking' and the proliferation of anti-patterns and code smells. They become a bad influence under whose spells developers, and perhaps even more teams, can fall and remain trapped.

I like the flexibility, and the diversity I get being a .NET developer. I would just like MS to adopt a stronger lead in making it easier for me, and others, to follow good practices. Happily there does seem to be some sight of some cavalry coming over the hill. In the web world the new ASP.NET MVC framework could go a long way to meet this critique, and perhaps Prism in the WPF world.