If you've been following my blog for a while, you might have noticed a distinct lack of coverage on all the exiting new things happening on the .NET platform lately. The reason I've kept unusually quiet, is basically because I don't feel the web really needs yet another blog sprouting Hello, World posts about Linq, WPF, WCF, Silverlight and so forth -there are a plethora of excellent bloggers taking care of that already. However, that is not to say I've not spent my fair share of late nights playing with these new toys.
What I think alot of people fail to notice when discovering the new language features that have been introduced with C# 3.0, is the fact that they are pretty much all there to make LINQ possible. Let me rephrase that - they're pretty much all there to make the LINQ queries look nicer. LINQ would still work without them - because the new language features add nothing to the language that we couldn't already do in C# 2.0. They're what we call syntactic sugar, or compiler magic. Here's some code to clarify:
static void Main(string[] args)
{
List<Customer> customers = GetCustomers();
// a simple linq query
var res1 = from c in customers where c.City == "Seattle" select c.Name;
// which is just fancy syntax for
var res2 = customers.Where(c => c.City == "Seattle").Select(c => c.Name);
// the lambdas are just fancy looking delegates
Func<Customer, bool> filterDelegate = new Func<Customer,bool>(FilterCustomers);
Func<Customer, String> selectDelegate = new Func<Customer,string>(GetCustomerName);
// the var is just telling the compiler to figure out what the return type was - but we can figure it out too
IEnumerable<String> res3 = customers.Where(filterDelegate).Select(selectDelegate);
// and the extention methods are really just static members on a static helper class
IEnumerable<String> res4 = System.Linq.Enumerable.Where(customers, filterDelegate).Select(selectDelegate);
}
private static bool FilterCustomers(Customer c)
{
return c.City == "Seattle";
}
private static string GetCustomerName(Customer c)
{
return c.Name;
}
Looking at that code, its easy to see the motivation behind adding these new features - just see how much more verbose the last version of the query is compared to the first. And this is a very simple query - imagine how bloated it would look for anything half-advanced. Its quite brilliant, really.
So why do I feel the need to stress this point? Because what I've seen out on the web so far is a trend thats starting to somewhat scare me. People are jumping on these features like hungry puppies, littering the code with scraps of it in their digestive conquest.
You're Breaking My Encapsulation
The most notorious examples of the misuse I'm seing is with extention methods. People are extending BCL classes left and right. While it is perfectly understandable that someone might think adding methods like IsEmail() to the String class is helpful, from an architectural point of view it is just wrong. Because what is the String class, really? It's an ecapsulation of a string of characters. Thats it. That is all it ever wanted to be in this life, and it was content being it. When you start giving it methods like IsEmail() you're breaking that encapsulation, dilluting the cohesion of the class. It's no longer a String class - its a StringAndEmail class. And if there is one thing that any object oriented programmer should live and breathe by, it is the single responsibility principle.
Now I'm not saying that extention methods are inherently bad - just that they seem to make a lot of people forget the larger picture. The String class might very well benefit from having some new members, but please make sure they really do belong on the String class - there's a reason the BCL team chose Int32.Parse(string) instead of String.ToInt32(), for example. You can throw any name you like at it - separation of concerns, encapsulation, loose coupling - they should all stick.
