Is it a bad idea to expose inheritance hierarchy in namespace structure?

Question

I've got a group of inter-related classes that are all overridden together to create a particular implementation. I'm wondering if it is a good idea to enclose the interrelated subclasses in a namespace.

For example purposes, consider the following namespaces and classes:

namespace Protocol
{
  public abstract class Message { }
  public abstract class Driver { }
}
namespace Protocol.Tcp
{
  public class TcpMessage : Message { }
  public class TcpDriver : Driver { }
}
namespace Protocol.Ftp
{
  public class FtpMessage : Message { }
  public class FtpDriver : Driver { }
}

What is the best way to structure the namespaces? It seems unavoidable to expose the inheritance in the namespace since the base classes don't really belong in either the Protocol.Tcp namespace or the Protocol.Ftp namespace.

Answer 1

I think you are perhaps worrying too much!

Does it make sense logically? Do you know where to find your code within the namespaces?

I would much rather see a codebase like the above with a small number of classes, relevant to the name with a hierarchy, than one large namespace where everything is interrelated..

Remember, namespacing is there for precisely this, to organise your codebase logically

What you have seems logical :)

EDIT:

As an example:

using System.Data;
using System.Data.Sql;

;)

Answer 2

If this were me, I would define 2 namespaces:

Protocol

and

Protocol.Driver

Dividing the namespace like this separates your "library code" vs your "executable / test code." I also create my namespaces to match the directory structure; it will give logic to your programs structure and codefiles. (maybe you already do this...)

Answer 3

@Brad Barker I don't currently have classes with multiple inheritance but if I need to add another base class for multiple inheritance I'm thinking there are two possibilities:

• If the other base class is in Protocol, TcpMessage and FtpMessage can reference it directly.
• If the other base class is in some other namespace, TcpMessage and FtpMessage can add a using directive to reference the other namespace.

Essentially I'm not requiring that the namespace hierarchy exactly match the inheritance hierarchy, I'm just wondering if its a bad idea to expose any information about the inheritance at all.

Answer 4

The original tags show that this post is about C# - therefore multiple inheritance is an irrelevancy - you can't multiply inherit in C#.

Maybe you should consider defining some interfaces that define what the basic contracts of a Message and a Driver are and then you may feel a little free-er to use the namespace structure to mimic the technology differences.