我认为在C#中强制执行命名空间而不是程序集(内部)之间的类型可见性可能很有用。
似乎这样的概念可以帮助开发人员使用代码库,确保在提供类似功能的另一个内部类型可用的地方使用正确的类型,但会导致“架构”缺点(不必要的依赖性等)。
其他人认为这会有用吗?目前是否可行?如果不是为什么不呢?
此外,preclusions的概念 - 在命名空间和/或程序集之间对引用指定否定约束的能力是否是C#的有用补充?
答案 0 :(得分:3)
类型与定义它的程序集紧密绑定。命名空间不是,它可以出现在多个程序集中。例如System.Configuration。
让我们假设一个程序集的元数据格式将被更改(-1亿个点)来存储命名空间的属性。这些属性仍然必须存储在程序集中,因为这是元数据的存储单元。现在,您必须处理CLR加载另一个程序集并找到相同名称空间但具有冲突属性的可能性。怎么可能解决这个问题?
更严重的是,您如何防止外部代码仅使用相同的命名空间和属性来突然获取对私有的实现细节的访问权限。这完全破坏了拥有内部关键字的价值。
答案 1 :(得分:2)
您可以将它们公开,使用自定义属性标记它们,然后添加FxCop规则以检查来自命名空间外部的访问。
这不能安全地强制执行限制,并且在使用反射访问成员时失败,但如果只是关于策略/编码风格,这应该足够了。
我认为还有一个现有属性可以隐藏Intellisense中的成员,您可以将其与自定义属性结合使用。