Should I put extension methods of an interface in the interface.cs file?

Question

Imagine this set up:

public interface IMass{
    double Mass {get;}
}

public static class IMassExtension {
    public static double ToKg(this IMass massObject) {
        return massObject.Mass / 1000.0;
    }

    public static double CalculateInteractiveGravity(this IMass massObject, IMass otherMassObject)          
    {
         return blah;
    }
}

Is it ok to put the extension class in the same file as the interface (i.e. IMass.cs) or should it be in a separate file (IMassExtension.cs)?

A base class is not possible here. Imagine

public class Person : Animal, IMass {}

and

public class House : Building, IMass {}

@Yusubov Base class won't work here, updated question – Moop Aug 05 '14 at 17:19 — Moop, Aug 05 '14 at 17:19

score 13 · Accepted Answer · answered Aug 05 '14 at 17:34

Yeah, that's totally fine. Further, I would encourage you to do that, as it makes the functionality available in the interface more discoverable, while reducing the noise in the "what functionality is in this csproj?" view in visual studio.

The only arguments I've heard against this are:

"but then you have 2 types per file!" - guidelines are there to help you, not tie your hands. You'd make it only one type if you could.
"but that extension uses XYZ!" - yeah, if you wouldn't include the method if it were an abstract class, then you shouldn't hard-wire it to the interface either. That's not a problem with this practice, but with your design.

New language features pretty much enhance this further – user1496062 Apr 14 '20 at 06:51 — user1496062, Apr 14 '20 at 06:51

score 2 · Answer 2 · edited May 23 '17 at 12:40

In summary: Having the extension methods in a separate file would be the approach to go. It is also very important to name extensions appropriately, as that will definitely safe time during the maintenance.

I would definitely prefer the name MassExtensions over IMassExtensions. 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 Base Class Library. The majority of the extension methods available for IEnumerable are contained in the type Enumerable.

Following related posts might be helpful:

This blog post recommends against the same namespace: http://blogs.msdn.com/b/vbteam/archive/2007/03/10/extension-methods-best-practices-extension-methods-part-6.aspx — Moop, Aug 05 '14 at 17:49

score 1 · Answer 3 · answered Aug 05 '14 at 17:06

Normally, I wouldn't put extension methods in the same file as the interface. Same library/package? Sure.

In this example, I would definitely wouldn't. What if someone implemented mass in imperial units (slugs)? The toKg() should be in the interface (and maybe well as toSlug(), but that would technically be derivable from toKg()), and the extension methods would be methods like toG(), toMcg(), etc., which could be implemented using the interface methods.

score 0 · Answer 4 · answered Aug 05 '14 at 17:13

0

I would put it in a separate file, and I would give it a more descriptive name than "IMassExtension.cs". Perhaps something like "MassConversions.cs", since that's what the class actually does.

Don't forget, the extension methods can still be called as if they were simple static methods (e.g. MassConversions.ToKg(massObject) ), so the class should be named with that in mind. Also, your extension class isn't an interface, so it could be misleading to name it with the leading 'I'.

answered Aug 05 '14 at 17:13

Eric King

10,876
3
41
55

Well, this is just a simple example, I have a bunch of extension methods that do different things, and there is no good common name for it – Moop Aug 05 '14 at 17:16
That might be a sign that some further thought should be put into organizing the functionality. "Kitchen sink" classes are commonly sources for lots of agony, and should generally be avoided. Just because the functionality is surfaced in the form of extension methods is no reason to abandon good class structure. – Eric King Aug 05 '14 at 17:22
I updated the question to show a possible reason why it is useful for this design. – Moop Aug 05 '14 at 17:23
I see your update, and my comment still applies. Make separate (appropriately named) classes for separate types of functionality. In my opinion, plopping all of them in the same class is convenient, but sloppy. – Eric King Aug 05 '14 at 17:24
Are you saying that `Animial : Mass` and `Building : Mass` if `Mass` was a base class? – Moop Aug 05 '14 at 17:28
No, I'm saying that 'IMassExtensions' isn't a meaningful name, and encourages inclusion of a random assortment of functionality that just happens to be related to IMass objects. Instead, the functionality should be organized in a way that can be described better in the name of the class (MassConverter, for example). If you have lots of functionality that seems unrelated to conversions, put it into another class with an appropriate name (like GravityCalculator, or whatever). The fact that the functionality is exposed via extension methods is a technicality, and shouldn't drive the class naming. – Eric King Aug 05 '14 at 17:33

Should I put extension methods of an interface in the interface.cs file?

4 Answers4