views:

209

answers:

5

I typically name my C# interfaces as IThing. I'm creating an extension method class for IThing, but I don't know what to name it. On one hand, calling it ThingExtensions seems to imply it is an extension class to some Thing class instead of to the IThing interface. It also makes the extension class be sorted away from the interface it extends, when viewing files alphabetically. On the other hand, naming it IThingExtensions makes it look like it is an interface itself, instead of an extension class for an interface. What would you suggest?

Edit: there is not a Thing class that implements IThing, in response to some of the comments.

A: 

I would prefer putting it in a folder (and namespace) called Extensions and naming it IThingExtensions.

klausbyskov
+4  A: 

I definitely prefer the name ThingExtensions over IThingExtensions. The reason being that to most programmers an I prefix on a type implies that it is an interface. This is both a very common pattern and part of the .Net Design Guidelines.

Adding an I prefix for the extension method case breaks both assumptions and established guidelines.

There is also precedence for this in the BCL. The majority of the extension methods available for IEnumerable are contained in the type Enumerable.

JaredPar
I'm imagining that there's a class called `Thing` that implements `IThing`, therefore it would be confusing if it was called `ThingExtensions` but worked on `IThing`'s. But, @Sarah Vessels does not specify this...
klausbyskov
BCL = Base Class Libraries
Sarah Vessels
@klausbyskov: there actually isn't a `Thing` class that implements `IThing`. I'll update my question.
Sarah Vessels
+2  A: 

Most programmers I know put all of their extension methods for an application in a static class called ExtensionMethods (or something like that), regardless of the class the extensions modify, and then they put this class into their main program namespace.

Their rationale is that, if you put the extension method in the same namespace as the class it modifies, you can confuse the method with the methods that are part of the actual class, which suggests that the extension method is part of the original functionality when it isn't.

Their isn't universal agreement on this, of course. See here: http://stackoverflow.com/questions/2520446/how-do-you-manage-the-namespaces-of-your-extension-methods

Robert Harvey
+4  A: 

I, personally, would use IThingExtensions.

From a usability standpoint, the end user never sees this class - they only include it's namespace. If the namespace is the same as IThing, then it doesn't matter - they'll already have it.

That being said, I think that the fact these are extensions for any IThing makes IThingExtensions the most clear. If you have a Thing class, calling this ThingExtensions may seem ambiguous (are you extending the interface or the implementation itself?).

That being said, the framework uses a very different approach. The framework's approach is to use a class named Thing to extend IThing. For examples, see Enumerable (extending IEnumerable) and Queryable (extending IQueryable). This would also be a very good option.

Reed Copsey
I follow the framework's approach in my projects. Hasn't lead to any nasty side-effects yet.
Programming Hero
@Programming: It works great, provided you don't have a default implementation for `IThing` that's named `Thing`...
Reed Copsey
I still don't like this approach because it violates the design guidelines for type naming. In particular only prefix type names with an I if it's actually an interface. http://msdn.microsoft.com/en-us/library/ms229040.aspx
JaredPar
@JaredPar: Yes, but unfortunately, the design guidelines don't really have any guidance for naming Extension method classes - they really just talk about when to use them (ie: http://blogs.msdn.com/brada/archive/2009/01/12/framework-design-guidelines-extension-methods.aspx) Using Thing is my preference unless you're making a Thing class - in which case, ThingExtensions becomes confusing... Hopefully, there will be official guidance on this at some point.
Reed Copsey
Luckily, however, the user never uses the class name, so the extension method class name is (effectively) an implementation detail, and not part of the API. The user only "uses" and "knows" the namespace name directly.
Reed Copsey
@Reed agreed they are a bit silent on the naming convention. But in the absence of one I usually fall back to precedence and for the BCL and most of VS APIs the precedence is `ThingExtensions`. Additionally it seems unlikely the design guidelines would come out in favor of `IThingExtensions` because it would mean too much existing code was no longer up to par. My guess is they will continue to remain silent on the subject
JaredPar
@JaredPar: Does the BCL use "ThingExtensions" anywhere? Every BCL class seems to use "Thing"... This is my preference (and what I typically do) unless there is a "Thing" class, in which case it gets confusing :(
Reed Copsey
@Reed, Not that I know of. The new Visual Studio APIs have the `ThingExtensions` pattern in several places.
JaredPar
A: 

I am not aware of any standard convention for this. I would use either ThingExtensions or ThingInterfaceExtensions. I would stay away from IThingExtensions as you also suggested.

Tom Cabanski