11

Is there a standard for how solutions/projects are organized in regards to interfaces and the classes that implement them? I'm working on a an MVP, DDD application and would love to hear feedback as to how others layout their projects and why they do it that way. Thanks!!

Cognitronic
  • 1,426
  • 2
  • 16
  • 29

3 Answers3

12

They should live in the namespace that is logical for them; this means that there's no firm rule for whether or not they should reside in the same namespace. You'll find relatively abstract namespaces often don't live alongside their implementation, whereas interfaces that are more 1:1 with their implementors are more likely to remain alongside one another.

A more important consideration is to keep the interfaces consumable for reuse--normally this means more consideration given to what goes into the assembly alongside the interfaces, rather than the namespaces.

STW
  • 44,917
  • 17
  • 105
  • 161
4

Check Martin Fowler's pattern on Separate Interfaces, it might help you decide where to put them.

Pablo Fernandez
  • 103,170
  • 56
  • 192
  • 232
  • 1
    +1 Interesting, I knew tris as the [dependency inversion principle (pdf)](http://www.objectmentor.com/resources/articles/dip.pdf). – Jordão Jan 26 '11 at 03:31
  • Cleared my doubt a bit on this situation: http://stackoverflow.com/questions/5840219/why-should-we-place-interfaces-with-classes-that-use-them-rather-than-those-that – Sidharth Panwar Apr 30 '11 at 08:23
1

There is certainly no compelling reason to do that.

In fact, if the users of the interface need not be aware of the concrete class, and if there are multiple implementations, and if the group defining the interface is different from the group implementing a certain version of it (all of which are valid cases), then it is probably wise to separate the implementation and interface namespaces.

I am not too sure about C#, but in Java, package membership is an important organizational pattern to enforce method visibility. If you want to make use of package-private things you basically have to group implementation classes together in the same package (so that you probably cannot put them together with the interfaces).

Thilo
  • 257,207
  • 101
  • 511
  • 656
  • Right, I have been creating my projects with a namespace for domain objects and a different namespace for their interfaces. I was looking at a few example projects online and noticed that they grouped their domain object interfaces and concrete implementations together and just wanting to see if that's how most do it. – Cognitronic Jan 26 '11 at 02:25