I have VB.Net project, with a class with a couple of abstract (mustoverride) properties, that I am thinking about moving into an interface.

My question, is structurally how do I do this? Currently all of the classes that would be implementing this are derived from this base class, so it might make sense to put it in the same file. Or I could create a separate interface file and put it in the same directory as the base class. Another option, would be to create a separate directory for interfaces (of which the project currently has zero) and put the file the.

After writing this up, I'm strongly inclined towards the second option. I've looked around, but haven't found any guidance on this. What would be the best option and why?

2 Answers 2


Common guidance in .NET land, in most cases, is to have every class and interface in their own file. With a 1:1 correspondance between files and classes, navigation becomes easier. This argues against option #1.

Regarding the choice between #2 and #3, I would argue for the former, with some caveats. I don't think you should have a folder for interfaces, but rather a folder structure based on the domain model. Group your files by subject, not into classes vs. interfaces.

The main caveat, though, if that once your application gets bigger, it might get split off into different projects, and not all projects can reference the project where the interface might be defined. In this case, we'll often create a separate project for contracts and interfaces, which is then referenced by other projects.

  • In your last sentence, do you mean to make one project where all interfaces can be placed? For example a project named 'Interfaces' with some logical structure in it based on the domain model. And all other projects with implementations would reference the Interfaces project? If this is fine, then I have another question; Is it a good practice to split up the Interfaces project into sub domains?
    – Ozkan
    Jul 26, 2018 at 8:34
  • 1
    Yeah, that's a pretty common pattern. If you have "MyProject.Core.dll" and "MyProject.ModuleA.dll", you might want to have a "MyProject.Interfaces.dll". That way you can have interfaces that are used by both libraries without creating circular depedencies. Jul 26, 2018 at 8:36
  • Is it a good practice to split up the Interfaces project into sub domains then? So how will my solution look like in the solution explorer (in case of .NET). several implementation projects and several interface projects. what are the best practices for naming those projects. Any articles you recommend? I love reading about this.
    – Ozkan
    Jul 26, 2018 at 8:39
  • Does this 'common pattern' have a name? Where can I read more about this?
    – Ozkan
    Jul 26, 2018 at 8:44
  • I think you should ask a new question. Or come to C# Chat. Jul 26, 2018 at 10:20

I would group all my classes and interfaces in a separate folder. Everything should be grouped by functionality and not by whether it is a base class, an interface or whatever.

What would happen if you had a complex design pattern, would you subdivide the interfaces in separate folders?

  • +1 for grouping by functionality. MS got that absolutely wrong with the way they set up many template projects. Jul 6, 2013 at 18:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.