暴露名称空间结构中的继承层次结构是一个坏主意吗?


3

我有一组相互关联的类,它们都被重写在一起以创建特定的实现。我想知道是否将相关子类放入命名空间是一个好主意。

例如目的,考虑下面的命名空间和类:

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 { } 
} 

什么是组织命名空间的最佳方式?由于基类不属于Protocol.Tcp命名空间或Protocol.Ftp命名空间,因此在名称空间中公开继承是不可避免的。

6

我想你可能太担心了!

逻辑上是否合理?你知道在命名空间中找到你的代码吗?

我宁愿看到类似上面的代码库有少量的几个类,有关与层次结构的名称,不是一个大的命名空间,一切都是相互关联的..

记住,命名空间是有精确这一点,组织你的代码逻辑

你有什么似乎是合乎逻辑:)

编辑:

为例:

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

;)


0

如果是我,我会定义2名的命名空间:

Protocol 

Protocol.Driver 

划分的命名空间这样的分离你的 “库代码”与你的“可执行/测试代码”比较。 我也创建我的名字空间来匹配目录结构;它会给你的程序结构和代码文件提供逻辑。 (也许你已经这样做...)


1

原标签显示这篇文章是关于C# - 因此多重继承是一种无关紧要的 - 你不能在C#中继承乘法。

也许您应该考虑定义一些界面来定义MessageDriver的基本合同,然后您可能会觉得有点空闲 - 使用命名空间结构来模拟技术差异。