5

I found some questions about how to organise projects (namespace, one class per file etc), but on a more specific note, how do you organize "things" that are very tightly related ?

I usually end up with :

  • an interface IMyStuff
  • a base (sometimes abstract) class that provides basic skeletton for that interface : BaseMyStuff
  • implementation classes MyStuffWithBellsAndWhistles, MyStuffWithChocolateFlavours

It seems to make sense that they should be in the same namespace, but it feels like my folders start to be a bit over-crowded if I put all these files together in the same folder (not actually a real problem, but it feels strange).

Would it be OK to define both the interface and the base class in the same file ?

Or would it be OK to group those things in sub-folders, but in the same namespace ? like this : 

-MyNamespace
 |-Interfaces
   | -IMyStuff
   | -IMyOtherStuff
 |-BaseClasses
   | -BaseMyStuff
   | -BaseMyOtherStuff
 |-Implementation
   | -MyStuffWithAwesomeBehaviour
   | -MyStuffWithGreatUsefulness
   | -MyOtherStuffSoNeatYouWillCry

What are the "best practices" regarding this kind of organization ?

tsimbalar
  • 5,790
  • 6
  • 37
  • 61

1 Answers1

0

If the purpose of the interfaces is to abstract the implementation and allow for alternative implementations that are not known to the author of the interface, then I would recommend keeping them in an seperate project file. When constructing unit test projects or other consumers of the interface this will allow them to create a project reference that drags in only the interfaces and not the implementations. This means alternative implementations of concrete classes never need to have a reference to the original concreate representation.

PhillipH
  • 6,182
  • 1
  • 15
  • 25