在可以修改的类上使用扩展方法是否可以接受

Question

我最近一直在考虑使用扩展方法在我控制的类上实现辅助工具(即,在同一个程序中,我可以修改).它背后的基本原理是,很多时候,这些辅助工具在非常特定的场景中使用,并且不需要访问类的内部值.

例如,假设我有一个StackExchange类.它有像PostQuestion和Search和的方法AnswerQuestion.

现在,如果我想手动计算我的声誉以确保StackOverflow不会欺骗我,该怎么办？我会实现以下方面的内容:

int rep=0;
foreach(var post in StackExchangeInstance.MyPosts)
{
  rep+=post.RepEarned;
}

我可以向StackExchange类添加一个方法,但它不需要任何内部,并且它仅用于程序的一个或两个其他部分.

现在想象一下,如果你有10或20个这些特定的辅助方法.在某种情况下肯定有用,但绝对不适用于一般情况.我的想法是改变像

public static RepCalcHelpers
{
  public static int CalcRep(StackExchange inst){ ... }
}

喜欢的东西

namespace Mynamespace.Extensions.RepCalculations
{
  public static RepCalcExtensions
  {
    public static int CalcRep(this Stackexchange inst){...}
  }
}

注意命名空间.理想情况下,我会使用它来在特定场景中对扩展方法进行分组.例如,"RepCalculations","Statistics"等.

我已经尝试过搜索是否听说过这种类型的模式,并且没有找到任何证据表明扩展方法被用于除了你无法修改的类之外的任何东西.

这种"模式"有哪些缺点？我应该坚持继承或组合,还是只是一个好的'静态助手类？

Answer 1

我会阅读《框架设计指南》中有关扩展方法的部分。这是第二版的一位作者的帖子。Phil Haack 引用您所描述的用例（专用帮助器方法）作为扩展方法的有效用途，其缺点是需要额外的 API 知识才能找到那些“隐藏”方法。

在那篇文章中没有提到，但书中建议的是，扩展方法进入与扩展类不同的命名空间。否则，它们将始终与智能感知一起出现，并且无法将其关闭。