是否有任何最佳实践表明不应将自定义代码放置在 System
命名空间中?System
及其子项是否应保留给 Microsoft 代码?
Are there any best-practices that state custom code shouldn't be placed in a System
namespace? Should System
and its children be reserved for Microsoft code?
我问是因为我正在编写一个将在许多项目中使用的类库,我想通过将它放在 System.InteropServices
中来保持一致性(因为它处理 P/调用).
I ask because I'm writing a class library that will be used across many projects and I'd like to keep things consistent by placing it in System.InteropServices
(since it deals with P/Invoke).
这不是一个好主意,因为它破坏了命名空间的主要好处之一:防止名称冲突.如果较新版本的框架在该命名空间中引入了同名类型怎么办?
It's not a good idea because it defeats one of the primary benefits of namespaces: preventing name clashes. What if a newer version of the framework introduced an identically named type in that namespace?
这对于 System
命名空间尤其不利,因为它们是通过 using
指令导入到许多其他代码段中,并且在这些命名空间中引入自定义类型会污染其他命名空间的命名范围带有意外标识符的源文件.
This is particularly bad for System
namespaces since they are imported in many other pieces of code with using
directives and introducing custom types in those namespaces pollutes the naming scope of other source files with unexpected identifiers.
要对您的自定义互操作相关类型进行分类,您可以创建一个新的命名空间,例如 MyProduct.InteropServices
.
To categorize your custom interop related types, you can create a new namespace like MyProduct.InteropServices
.
这篇关于将自定义代码放在系统命名空间中的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持跟版网!