我可以强制C#中的命名空间之间的依赖关系

时间:2010-07-20 12:41:41

标签: c# namespaces class-design

我可以限制特定命名空间中的类引用另一个特定命名空间中的类吗?两个名称空间都存在于同一个.NET程序集中。

示例:

namespace LegacyCode
{
    class LegacyClass { ... }
}

namespace NewCode
{
    class NewClass {...}
}

我不希望'NewCode'中的类能够引用'LegacyCode'中的类。

选项:

  1. 拥有不同的程序集(使部署更加困难,构建需要更长时间)
  2. 使用像NDetect这样的工具(花钱!)
  3. 有没有人有其他想法?

5 个答案:

答案 0 :(得分:10)

考虑使用Obsolete attribute标记类。这将导致任何本身未标记为“已过时”的代码在编译期间生成警告。

在项目文件的“构建”选项卡上启用“将警告视为错误”设置,以使此警告无法通过编译而无法编译。

编辑:

同意单独的程序集是一个很好的策略,可以帮助淡出这段代码。这不会阻止人们提到它。过时的属性清楚地表明这个代码已经过时了。

编辑#2:

感谢Dan Tao指出了Obsolete属性的overloaded constructor。这意味着您可以强制是否应将某事物的使用视为错误,而不必将处理警告视为错误。还有用的是指定指示用户解决方法的消息的选项。编译期间在错误/警告中显示此消息。

答案 1 :(得分:7)

记录设计,与人交谈,审核代码。不要试图将技术抛给人们的问题。 (不过,使用像NDetect这样的工具,评论部分可以变得更有效。)

如果您确实需要隔离设计更改,请选择单独的程序集:这是预期的设计机制。但请确保您对接口和实现都有合理的版本控制方案。

答案 2 :(得分:3)

我认为单独的装配是唯一可能的解决方案。

答案 3 :(得分:3)

MS使用System.ObsoleteAttribute属性来标记过时/遗留代码。此属性提供了一个创建编译器错误的ctor。但是,如果没有太多遗留类,我会使用它。

答案 4 :(得分:1)

正如其他人所说,使用过时的属性(即使你必须重命名它)。

但更进一步。删除任何不再使用的遗留方法。这样可以防止有人以后再使用它。您应该开始看到由于过时属性导致的编译器警告随着时间的推移而丢失。

你甚至可以每天进行一小时的测试,以消除尽可能多的编译器警告......也许你在工作之后投入购买每日获胜者的啤酒(或软饮料......;)。 p>