views:

166

answers:

7

Should my interface and concrete implementation of that interface be broken out into two separate files?

+3  A: 

If there is only one implementation: why the interface?

If there is more than one implementation: where do you put the others?

João da Silva
Why the interface? For testability. Mocking rocks :)
Jon Skeet
Agreed that even if there's only one concrete class it should be interfaced. Still, I'd use a separate file.
ctacke
But then the mock is another implementation, so both implementations should go in separate files.
João da Silva
I very rarely write an actual mock class directly. I use Rhino.Mocks etc - so the mock is built dynamically during the test.
Jon Skeet
+9  A: 

If you want other classes to implement that interface, it would probably be a good idea, if only for cleanliness. Anyone looking at your interface should not have to look at your implementation of it every time.

Elie
+1  A: 

If by different files you mean different xxx.cs files within your assembly, then normally due to my own practices I would say yes - but this is down to the house standards you use. If you're just programming for yourself, then I would say this is good coding practice, it keeps everything clean and easy to read. The smaller the blocks of code in any given file, the easier something is to follow (within reason), obviously you can start getting into partial classes where things can start getting ridiculous if you don't keep a reign on it.

As a rule, I keep my projects in a logical folder structure where portions of the project might be allocated into folders DAL or BM and within there I might have a number of logically named folders which each contain a number of files: one interface, one implementation and any helper classes specific to those.

However, all that said, your team/in-house best practices should be adopted if you're working within a team of developers.

BenAlabaster
A: 

Separate files... FTW! You might even want to create separate projects/assemblies depending on how extensible your code is. At the very least it should probably be in a separate namespace.

The whole point of an interface is so that the code that uses the interface doesn't care about the implementation. Therefore they should be as loosely associated as possible, which they won't be if they are in the same file.

But as @balabaster notes, it depends on what your team's practices (although they are not always "best practices") are.

Mike
A: 

Yes, for the classes they're called partial class, take a look link text

tanathos
Unless I'm having brain fade, partial classes are a very different thing...
ZombieSheep
uhm... maybe I don't understand the question... I know that the partial classes (wich can implement an interface) can be split in one or more files .cs ...
tanathos
A: 

General rule of thumb, yes. An Interface means it may be implemented by other classes, it is cleaner and easier to manager when they are clearly in separate files.

What's more, depending on the level of separation and isolation your application is going to take, you would even want to place your interfaces in its own project. Then consuming projects would reference the interface project instead of each and every assembly that carries implementations of that interface.

icelava
A: 

Yes, even if one gives counter arguments such as there's only one implementation or he/she foresees that there will be only one implementation for a long time or he/she is the only user/developer, etc. If there are multiple implementations, multiple users, etc, then it's obvious that you would want to keep them in separate files. So why should one treat it differently in the case of one implementation only?

Khnle