Extension methods were a new feature in .NET 3.0 (they are also supported by the 2.0 CLR). The single responsibility principle (SRP) is a strategy for structuring our code to make it more maintainable and testable. In this post, I’m going to discuss how we can use extension methods to make our code easier to read and satisfy the idea behind SRP.
As I mentioned, extension methods were a new feature in .NET 3.0, and they’re compatible with the 2.0 CLR. They’re backwards compatible because they’re simply a compiler trick. In fact, you may already have methods that are only one step away from being considered extension methods.
Here is a method that is not an extension method (we’ll come back to those in a bit):
public static Report GenerateReport(ReportData data)
{
//Create a report from the report data
}
A method like this is useful because it avoids cluttering another class with unrelated functionality. Imagine the opposite situation in which case the report data class is responsible for the data in the report, as well as the formatting of the report. The single responsibility principle tells us that we should separate the operations so that each class has only one reason to change. In practice, I have personally seen the advantages in code maintainability, readability, and testability. I won’t delve deeply into the supporting information in this post.
So how do extension methods come into play? As I mentioned, they’re simply a compiler trick. If we wanted to convert the aforementioned static method into an extension method, we simply add the “this” keyword before the first parameter, which is the type that our method is acting on:
public static Report GenerateReport(this ReportData data)
{
//Create a report from the report data
}
Now we’ve added an additional way to call our method:
var reportData = new ReportData(); //Old way of calling - still works in either case var r = GenerateReport(reportData); //New way of calling with extension method var r = reportData.GenerateReport();
Our method still works the way it always did when it was static, but now we have an additional way to call it. It’s also important to note that the extension method doesn’t have any extra permissions in regards to accessing the other class. It has to use its publicly exposed interface. In fact, if we wanted to rely simply on the interface instead of the implementation, we could modify our extension data to work on an interface such as IReportData.
The entire reason that extension methods exist is to make the calling syntax easier to read. The driving force was the new LINQ functionality. In particular, chaining the old static method syntax quickly becomes cumbersome.
The new extension method syntax allows us to make the calling code more elegant, and yet organize our methods so that there are clear boundaries between the pieces of functionality that we’re wiring together. Extension methods are obviously not always the best way to follow SRP, but they certainly give you a new tool in your toolbox.
I believe this is an abuse of Extension methods.
Tuna, why would you feel that way?
I think this is the absolute intention of extension methods.
I agree with you poster that this is a much preferred solution than having helper classes every where.
Hi Chris,
The thing is that Extension methods should be used when you can’t modify the code. I also believe that, if you want to provide an SRP with a lot flexibility, you can have
IReportGenerator
{
IReport GenerateReport(ReportData);
}
I _believe_ you shouldn’t use Extension Methods jst for the sake of SRP.
Anyway this issue sounds more of a personal taste, doesn’t it?
Tuna, your approach would work fine. Maybe my example wasn’t the best since reporting is probably an involved operation. Most of the time, I do it as you described. I just thought this was a fairly elegant solution for certain cases where the overhead of your approach might be a bit too much.
The point was that there are other ways of separating your code while still operating a certain interface.
People may already be doing this, and the other point I was trying to make was that extension methods give us a little more elegant way of “attaching” this functionality.
I just hate static helper classes, they are so .NET 2.0. I feel any method that can be put into a static helper class should be an extension method in .NET 3.5. If there’s ever a point where the implementation might need to change based on the object implementation or what class implements the interface that it should be moved internally to the class as a regular method.
Hi
Does subversion VM has LDAP authentication ?
Jason,
I believe extension methods must be used with very high caution in that they don’t belong to the class or interface they act in, so when extending the class or implementing the interface, extension methods code are not inherited. Talking about interfaces, as extension methods are not part of the interface’s contract, their existence and signatures aren’t even checked on implemented classes.
I agree…this is an abuse of Extension Methods