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 {}
1
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.
1
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:
- C# – using extension methods to provide default interface implementation
- C# Extension methods namespace and promoting extension methods
2
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.
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’.
6