logo标签列表

扩展方法命名空间和赞助类的命名约定

.net-3.5naming-conventionsextension-methods
17

你使用哪些命名约定来命名命名空间和扩展方法定义的类？（即容纳扩展方法定义的类）

是否有标准/推荐的.NET Framework命名约定？（“框架设计指南，第二版”书籍只提供不应使用哪些命名空间的指导）。

3个回答
13

我没有看到任何官方建议，但我一直将我的扩展类组织成[命名空间].[类名]Extensions的形式:

ProjectName.Web.Util.ControlExtensions
ProjectName.Data.Util.CollectionExtensions
3
我也这样做，并且我还会把任何高度专业化的静态扩展方法类放到与其使用相关的命名空间中，以便它们不会影响其他开发人员的智能感知。换句话说，我的扩展方法类并不一定与它们扩展的类在同一个命名空间中。 - jpierson
2
我做了类似的事情，但是当我将扩展方法添加到接口而不是类中时，我最终得到了丑陋的类名，例如IMyInterfaceExtensions，看起来像扩展类本身就是一个接口:( - mo.
8
对于命名空间-我会专注于命名空间名称的标准框架指南。将扩展方法放入一个命名空间中，这个命名空间通常与它们相关联并有意义，并避免为此使用额外的命名空间。
对于赞助商类别-在这种情况下，这并不是非常重要。我会尝试选择一个有意义的类名，但似乎没有固定的指导方针。
然而，这里的重要事情是，赞助商类别从未真正被扩展方法的用户直接使用/看到。只要已经包含了命名空间，扩展方法就能够正确地找到。我个人对我的扩展方法使用类似jrummell的东西，但微软在框架中没有遵循这一点（这是Enumerable类的一个很好的例子）。
1
Reed和jrummell的回答都很好。我将把这个标记为“最佳”答案，因为它更深入地探讨了问题。不过需要注意的是，在不支持扩展方法的.NET语言中，赞助类名称确实很重要，因为必须使用经典的静态方法调用。 - Milan Gardian
-1

对于文件名和类名，请使用Extensions后缀。例如，如果您想为名称Foo创建扩展方法，请将其命名为FooExtensions并将其放置在名为FooExtensions.cs的文件中。

如果您有许多扩展类，请将它们放入一个名为Extensions的目录中。

我看到微软使用与他们希望扩展的类相同的命名空间。这样，它们就可以轻松地被发现和使用，而无需通过using语句导入它们。

“同一命名空间作为类”是错误的，名称空间主要是为了避免冲突，只有名称空间所有者（例如某个库）才被允许使用相同的名称空间。 - Top-Master
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接