Are interdependent child / parent namespaces related to code smell?

Question

I recently looked at some dependency graphs for my main personal project, and I noticed that I had a mutual dependency between objects in nested namespaces. For example, I had an object in MyNamespace.Foo that implemented a common interface in MyNamespace.Foo.Interfaces with this object as a general parameter in the interface.

 namespace MyNamespace.Foo { internal class Foo : MyNamespace.Foo.Interfaces.IFoo<Foo> { } } 

In this case. the dependency analysis tool (VS2010 beta) intelligently considers the generalized "instantiation" (for discussion I know that this is not C ++) of the interface is a member of the Interfaces namespace, which then depends on its parent namespace.

After some consideration on my part, I more or less came to the conclusion that my existing design, in my particular case, is a code smell. I have to combine the Interfaces namespace into the parent Foo namespace. (It is foolish to require clients to deploy an additional layer in the interface namespace if I want them to use Foo through IFoo .) Is this true in the general case?

How to manage interdimensional dependencies? Should "wider" namespaces (e.g. MyNamespace.Foo generally depend on narrower namespaces (e.g. MyNamespace.Foo.Interfaces )) or should there be narrower namespaces depending on wider? Or is there a better, more subtle answer?

Answer 1

In the specific case of your example, I would combine the Interfaces namespace in the parent namespace.

In general, I think that narrower namespaces should depend on classes or interfaces, on wider ones, or those that are children of a common parent namespace. The second case is typical if you have a namespace, so the model namespace has common classes or interfaces that describe your model for the problem that your code is trying to solve.

I should also note that I do not think that these rules are necessarily applicable to third-party addicts. For example, depending on the code from the narrow namespace in Spring.NET , your code is not proprietary code.

Answer 2

If you want to separate the interface from the implementation, it may be the parallel namespace MyNamespace.Foo.Interfaces and MyNamespace.Foo.Implementation.

By default, the namespace appears to be equivalent to a package or assembly: therefore, Foo and Bar will be the namespaces for foo.dll and bar.dll respectively.

I will add prefixes to the namespace if I need higher-level groups: for example, MyCorp.Server.Foo is the namespace for the server side foo.dll created by foo.dll .

Note that I'm adding prefixes, not suffixes: like MyCorp.Server.Foo , not Foo.Server.MyCorp . These structured namespaces correspond to the folder / directory structures that contain the source code and projects.

By default, all files in the package will have the same namespace (for example, all code in foo.dll belongs to the foo.dll namespace). If I ever add a suffix, this may hide this code from the rest of the assembly. For example, code in the MyCorp.Server.Foo.EditorTransactions namespace exists in foo.dll but is not considered by most other codes in foo.dll (except for code that explicitly uses MyCorp.Server.Foo.EditorTransactions ).