I was looking at some dependency graphs for my primary personal project recently, and I noticed that I had a mutual dependency between objects in nested namespaces. E.g., I had an object in MyNamespace.Foo that implemented a generic interface in MyNamespace.Foo.Interfaces with that object as the generic parameter in the interface.
namespace MyNamespace.Foo
{
internal class Foo : MyNamespace.Foo.Interfaces.IFoo<Foo>
{ }
}
In this case. the dependency analysis tool (VS2010 beta) reasonably considers the generic “instantiation” (for the sake of discussion, I know this isn’t c++) of the interface to be a member of Interfaces namespace that then depends on its parent namespace.
After some consideration on my part, I’ve more-or-less reached the conclusion that my existing design, in my particular case, is a code-smell. I should merge the Interfaces namespace into the parent Foo namespace. (It’s silly to require clients to drill down an extra layer to the interfaces namespace if I want them to use Foo via IFoo.) Is this true in the general case, however?
How should inter-namespace dependencies be managed? Should “broader” namespaces (like MyNamespace.Foo generally depend on “narrower” namespaces (like MyNamespace.Foo.Interfaces), or should narrower namespaces depend on broader ones? Or is there some better, more subtle answer?
In the specific case regarding your example, I would merge the
Interfacesnamespace into the parent namespace.In general, I think that narrower namespaces should depend on classes or interfaces from broader ones, or ones that are a child of a shared parent namespace. The second case is typical if you have your namespaces arranged so that a model namespace has shared classes or interfaces that describe your model for the problem your code is trying to solve.
I should also note that I don’t think these rules necessarily apply to third-party dependencies. For example, depending on a code from a narrow namespace in Spring.NET in your code doesn’t constitute a code-smell.