views:

234

answers:

8

As as rule of thumb I generally put classes in a file of their own. Visual studio seems to encourage this but what is appropriate with regards to interfaces?

e.g.

I have Class Foo that implements interface Bar

public interface IBar
{

}

public class Foo : IBar   
{

}

it seems natural to group these within the same file until another class implements the interface but to dedicate a file to 2 lines code seems excessive but correct.

What is appropriate?

+21  A: 

I would split them into 2 files. I often found classes starting to go unmanageable when they are not in their own files.

Imagine trying to find class Foo in a file named IBar.cs or vice versa.

Adrian Godong
+ It's definitely more manageable both manually and through scripting.
SDX2000
Well if all I'm doing is extracting an interface for testability then a good place for it is in the class. When there is more than 1 implementation it the becomes more attractive to separate the two.
John Nolan
+2  A: 

Depending on the situation I either split each interface into its own file, or alternatively have an Interfaces.cs file, where I group interfaces in a given namespace together.

I'd never put an interface in the same .cs file as a class that implemented it.

tomfanning
+2  A: 

Since the purpose of an interface is to define a "contract" for (potentially) multiple implementing classes, I'd say putting the interface definition in its own file makes more sense. i.e. What happens if you also want to make Baz implement Foo?

ZombieSheep
A: 

In terms of encapsulation, each object, whether a class or an interface, should be in its own file. Even if the interface only contains one abstract method, the fact that it's in a different file allows for better organization and better encapsulation. You can store those different interfaces in a folder, give it an appropriate namespace, and therefore a cleaner solution.

johnofcross
I'd say that encapsulation is a property of the code itself, independent of where it's stored in the file system. It's generally useful to put things in helpfully-named files, but that's not part of encapsulation IMO.
Jon Skeet
+1  A: 

I have only two situations where I find myself putting multiple top level types in a single file:

  • If you're defining multiple delegate types. Each is only going to be a single declaration, so it makes sense to have a Delegates.cs file.
  • Sometimes it makes sense to declare that a whole bunch of autogenerated partial types implement a bunch of interfaces. Again, that's one line per type:

    // Actualy code is in the autogenerated file
    public partial class Foo : ICommon {}
    

Other than that, I use one file per top-level type, which goes for interfaces, classes and enums.

Jon Skeet
+1  A: 

Yes, having an interface implies that you are going to have more than one class with the same methods and properties definitions. Having it in one file for the moment is convenient as it is easy to modify without changing files. As time goes on you will and other classes use it, and if you have to make a change to it down the road you will have to hunt and peck for the right file.

Kevin
+2  A: 

You should certainly put the interface in it's own file. You may even consider putting the interface in it's own class library. If the interface will be used by two different classes in two different libraries, it makes sense to put the interface in a third library, so you don't have to include any specific implementation if you want to add the interface to a new project. In the third library you might also place classes that work with classes that implement the interface (public void Cook(IBar x), for instance).

quillbreaker
+1  A: 

I always put them into separate files. Having more than one type per file is just distracting IMO. I might make a folder "Interfaces" for them though. Also i think you shouldn't modify them as often as your actual implementations, anyway, so having them separated at least promotes that a bit.

Botz3000