Are mutually-dependent child/parent namespaces a code smell?

Question

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?

Answer 1

In the specific case regarding your example, I would merge the Interfaces namespace 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.

Answer 2

If you want to separate interface from implementation, a possibility would be parallel MyNamespace.Foo.Interfaces and MyNamespace.Foo.Implementation namespaces.

The default seems to be that a namespace is equivalent to a package or assembly: so Foo and Bar would be the namespaces for foo.dll and bar.dll respectively.

I'll add prefixes to the namespace if I want higher-level groupings: for example MyCorp.Server.Foo is the namespace for the server-side foo.dll produced by MyCorp.

Note that I'm adding prefixes, not suffixes: so MyCorp.Server.Foo rather than Foo.Server.MyCorp. These structured namespaces correspond to the folder/directory structures in which the source code and the projects are contained.

By default, everything file in a package will have the same namespace (e.g. all code in foo.dll belongs to the MyCorp.Server.Foo namespace). If I do ever add a suffix, this has the effect of hiding that code from the rest of the assembly. For example, code in the MyCorp.Server.Foo.EditorTransactions namespace exists in the foo.dll but isn't seen by most of the other code in foo.dll (except code which explicitly uses MyCorp.Server.Foo.EditorTransactions).