父命名空间中的类可以访问子命名空间中的类答案

【问题标题】：Can class in parent namespace access class that is in child namespace父命名空间中的类可以访问子命名空间中的类
【发布时间】：2013-08-09 11:17:55
【问题描述】：

我在命名空间Proj.Devices 中有一个Device 类。此类可以访问命名空间Proj.Devices.Messages 中的Message 类吗？两个类都在同一个项目中。我不是在问这是否可能，而是这是否是一种不好的做法？

我认为如果我将此项目拆分为单独的项目，循环引用会出现问题，否则可以吗？

编辑：我在Namespace Naming Guidelines找到了这个

“嵌套命名空间应该依赖于包含命名空间中的类型。例如，System.Web.UI.Design 中的类依赖于 System.Web.UI 中的类。但是，System. Web.UI 不依赖于 System.Web.UI.Design 中的类。”

【问题讨论】：

视情况循环引用是否发生，继承或引用其他命名空间类并没有错。一个很好的例子是如果你必须创建自定义控件，你可以参考其他命名空间调用 system.windows.controls 等。

【解决方案1】：

我不能同意莫比亚。命名空间不仅仅用于分组，它们是逻辑分离（组件），其中程序集是具体的分离（层和关注点）。

它们也经常被视为分层的。从哲学上讲，层次结构中较低的东西通过其父元素存在，而父元素可以在没有这个特定子元素的情况下存在。

我认为这就是为什么Core 命名空间现在存在的原因。基本命名空间只是基本结构/基础。

如果一个子命名空间被它的基础命名空间使用，你可以确定在大多数情况下会存在相互依赖：这揭示了架构风险。

应该避免，因为：

如果您不关心架构，那也不是问题。但是，如果您问自己这个问题，那么您已经在考虑编写好的代码了——这意味着新的用法即将到来，而不仅仅是为您自己;)-.

这就是为避免高耦合而存在这种做法的原因：

建筑是关于时间的，而不仅仅是美。在一定的成熟度下，无架构代码是可维护性、可理解性和可扩展性较差。

【讨论】：

【解决方案2】：

是的，他们可以，命名空间只是类的分组。不，这不是坏习惯，这是正常情况。

如果两个命名空间中的类相互引用，则将它们放在单独的项目中并不是一个好主意，只要它们在同一个项目中就可以了。

【讨论】：

在某处我读到这是一种不好的做法，我试图避免这种情况。结果，我认为我有更好的组织项目。很好的例子是提供者模式。具体提供者位于子命名空间 Pr.DevAccess.Providers 中，而接口位于 Pr.DevAccess 中。具体提供者可以依赖于 DeviceAccess 命名空间中的类型，但反之则不然。我尝试遵循以下两条规则： 1. 位于同一命名空间级别且具有共同父级的类可以相互依赖。 2. 子命名空间中的类不能依赖父命名空间中的类型。
好吧，在实际生活中，我总是有许多子文件夹来支持根目录中的主类的配置、缓存、管理器、助手等功能，该子文件夹将具有子命名空间并被使用通过父命名空间中的类。你提到的可能对 WCL 没问题。
对不起，我的意思是 BCL（基类库）而不是 WCL。