我有一组相互关联的类,它们都被重写以创建一个特定的实现。我想知道将相关的子类括在命名空间中是否是一个好主意。
出于示例目的,请考虑以下命名空间和类:
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命名空间,因此在命名空间中公开继承似乎是不可避免的。
答案 0 :(得分:6)
我觉得你可能太担心了!
逻辑上有意义吗?您知道在命名空间中找到代码的位置吗?
我更愿意看到像上面这样的代码库,其中包含少量类,与具有层次结构的名称相关,而不是一个大型名称空间,其中所有内容都是相互关联的。
请记住,命名空间就是这样,逻辑地组织代码库
你所拥有的似乎合乎逻辑:)
编辑:
举个例子:
using System.Data;
using System.Data.Sql;
)
答案 1 :(得分:1)
原始标签显示这篇文章是关于C#的 - 因此多重继承是无关紧要的 - 你不能在C#中多次继承。
也许您应该考虑定义一些定义Message
和Driver
的基本契约的接口,然后您可能会感觉有点自由使用命名空间结构来模拟该技术差异。
答案 2 :(得分:0)
如果这是我,我会定义2个名称空间:
Protocol
和
Protocol.Driver
将这样的命名空间划分为“库代码”与“可执行/测试代码”。 我还创建了我的命名空间来匹配目录结构;它将为您的程序结构和代码文件提供逻辑。 (也许你已经这样做了......)