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

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.

Answer 3

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...)