C# interface and implementation in the same file - good idea?_问答_开发者

I recently seen some C# code where the interface declaration and implementation where in the same file, like this

namespace MyNameSpace.Foo
{
    public interface IFoo{
        void DoThis();
    }
    public class Foo : IFoo {
        public void DoThis();
    }
}

At first glance it seems all wrong to have declaration and implementation in the same file, but there are practical benefits. e.g. When you Go To Definition in Visual Studio the interface and implementation are there in the same file. This approach does not prohibit you from having other implementations of the interface, such as may be need开发者_StackOverflowed for unit testing. For interfaces that will only have one implementation I think this can be a pragmatic approach.

Good or bad idea?

Extending the question:

How do people use Visual Studio to navigate to an implementation when you have an interface reference IFoo myFoo = FooFactory.getFoo(MY_FOO); If I right click on IFoo and select Go To Definition I can get the interface declaration. Is there a way for me to get the list of implementations of IFoo as that's what I'm really interested in getting to.

My recommendation is to always follow a rule of one item per .cs file, be it an enumeration declaration, interface or class. The name of the .cs file should match the name of the thing it contains.

Simple rule, easy to follow. We use StyleCop internally to police this.

If you combine this approach with a sensible use of namespaces then it should mean that your solution explorer view in Visual Studio makes it easy to navigate the components in your projects. Note that ReSharper gives an alternative approach to this navigation, but using this is not to everyone's tastes (and not everyone might have an Add-In such as ReSharper).

Travis G has asked about finer points such as delegates and custom EventArgs declarations. Since custom EventArgs are classes, I would put them in their own files (again, keeping the rule simple). Delegates I would declare with the class that uses them. If I found I had a lot of delegates that were used in many places I might consider placing them all in a Delegates.cs file (I sometimes do this with constants, in a Consts.cs file).

However, some of this is certainly subjective and getting into the realms of software religious wars.

Personally...

If an interface is only likely (in the short term) to be used for one class (like when providing an interface for dependency injection) then I will put it at the top of the class file. During development (when the class may be changing) it's a PITA to have to change two files each time the public surface changes.

Of course, if there is a chance that the interface will be implemented by more than one class then I put it in a separate file.

Having interface definition and implementation in same file has nothing to do with unit testing, as that interface will be available anyways.

I generally start with a simple interface and implementation on same file. When things grow up, I split them when other code needs to make reference to that interface.

I regard this as a Bad Idea.

Keep interface and implementation separated. Otherwise there are possibilities for you to mess up the design. Include the file and automatically get the implementation even if you only wanted the interface, then accidentally (because it is convenient) use the Impl instead of the interface and yay, close coupling.

I'd just stick to the "one class, one file" rule. With class I also mean interfaces, enums, etc.

And what's wrong with putting your cursor on the interface name and hitting F12?

Sure it does no harm to have it like this, and tools such as resharper will put the implementation below the interface in the code. However they also then give you the option to move the implemetation out into another file.

You're right, it doesn't stop you from exploiting the benefits of interfaces for unit testing, but you might want to consider putting interfaces into another assembly altogether. That way you could program against interfaces and swap implementations at will, giving you more separation. As ever there is no right or wrong answer, it just comes down to what you are trying to achieve.

I do that in java for small interfaces with few methods. In this case I provide one or more basic implementation in the interface file.

This avoid small classes scattered around.

But I can't say if it's a bad or best practices, although my co-workers never complained.

This is bad idea. If you are doing a really small and simple project, you don't need interfaces. If you need someday, you add it ad-hoc (in that moment in the specific class)

If you decide to use interfaces (big, professional projects), allowing enhanced dependency injection, unit testing with mocks and stubs and more polymorphism, than you probably will want to put the interfaces in different namespaces and assemblies (projects inside VS solution) than their implementations, following Clean / Hexagonal Architecture