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

我有一组相互关联的类，它们都被重写在一起以创建特定的实现。我想知道是否将相关子类放入命名空间是一个好主意。暴露名称空间结构中的继承层次结构是一个坏主意吗？

例如目的，考虑下面的命名空间和类：

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命名空间，因此在名称空间中公开继承是不可避免的。

来源

2008-08-20 Luke

我想你可能太担心了！

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

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

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

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

编辑：

为例：

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

;）

来源

2008-08-20 19:16:07

如果是我，我会定义2名的命名空间：

Protocol

和

Protocol.Driver

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

来源

2008-08-20 19:20:35 mmattax

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

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

来源

2008-09-23 21:52:37 Ronnie

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

回答

相关问题