永远不要让公众成员虚拟/抽象-是吗？

早在2000年代，我的一位同事就告诉我，将公共方法虚拟化或抽象化是一种反模式。

例如，他认为这样的课程设计得不好：

public abstract class PublicAbstractOrVirtual
{
  public abstract void Method1(string argument);

  public virtual void Method2(string argument)
  {
    if (argument == null) throw new ArgumentNullException(nameof(argument));
    // default implementation
  }
}

他说

• 实现Method1并重写的派生类的开发人员Method2必须重复参数验证。
• 如果基类的开发人员决定在Method1或Method2以后的可自定义部分周围添加一些内容，他将无法执行。

相反，我的同事提出了这种方法：

public abstract class ProtectedAbstractOrVirtual
{
  public void Method1(string argument)
  {
    if (argument == null) throw new ArgumentNullException(nameof(argument));
    this.Method1Core(argument);
  }

  public void Method2(string argument)
  {
    if (argument == null) throw new ArgumentNullException(nameof(argument));
    this.Method2Core(argument);
  }

  protected abstract void Method1Core(string argument);

  protected virtual void Method2Core(string argument)
  {
    // default implementation
  }
}

他告诉我，将公共方法（或属性）虚拟化或抽象化与使字段公开一样糟糕。通过将字段包装到属性中，可以在以后需要时拦截对该字段的任何访问。这同样适用于公共虚拟/抽象成员：以ProtectedAbstractOrVirtual类中所示的方式包装它们，使基类开发人员可以拦截对虚拟/抽象方法的所有调用。

但是我不认为这是设计准则。甚至Microsoft也没有遵循它：只需看一看Stream该类即可验证这一点。

您如何看待该指导方针？这有意义吗，还是您认为API过于复杂？

说

由于要实现Method1并重写Method2的派生类的开发人员必须重复参数验证，因此使公共方法虚拟或抽象是一种反模式

正在混淆因果关系。它假定每个可重写方法都需要不可自定义的参数验证。但这恰恰相反：

如果要设计一种方法，以便在类的所有派生类中提供一些固定的参数验证（或更笼统地说，是可自定义和不可自定义的部分），则使入口点成为非虚拟是有意义的，而是为内部可自定义的部分提供虚拟或抽象方法。

但是，有很多示例都拥有一个公共的虚拟方法是很有意义的，因为没有固定的，不可定制的部分：看看像ToStringor Equals或GetHashCode-这样的标准方法是否可以改善object这些类的设计，使它们不公开，并且同时虚拟？我不这么认为。

或者，就您自己的代码而言：当基类中的代码最终有意地看起来像这样时

 public void Method1(string argument)
 {
    // nothing to validate here, all strings including null allowed
    this.Method1Core(argument);
 }

之间具有这种分离Method1和Method1Core仅没有明显的原因复杂的事情。

按照您的同事的建议进行操作确实为基类的实现者提供了更大的灵活性。但是随之而来的还有更多的复杂性，通常无法通过假定的收益来证明。

记住，对于基类的实施者增加灵活性是以牺牲较少的灵活性，以压倒一切的聚会。他们得到一些他们可能不会特别在意的强加行为。对他们来说，事情变得更加僵化。这是合理且有用的，但这全都取决于场景。

实现此命名约定（我知道）是为公共接口保留好名字，并在内部方法的名称前加上“ Do”。

一种有用的情况是，当执行的动作需要一些设置和一些关闭时。就像打开流并在重写器完成后将其关闭。通常，相同类型的初始化和完成。它是一种有效的使用模式，但强制在所有抽象和虚拟场景中使用它毫无意义。

在C ++中，这称为非虚拟接口模式（NVI）。（从前，它被称为模板方法。这很令人困惑，但是一些较早的文章使用了这种术语。）NVI由Herb Sutter提倡，他至少撰写了几次。我认为最早的是这里。

如果我没有记错，前提是派生类不应该改变什么基类做，但怎么它做它。

例如，Shape可能具有Move方法来重新定位形状。一个具体的实现（例如，正方形和圆形）不应直接覆盖Move，因为Shape定义了Moving的含义（在概念上）。就内部位置的表示方式而言，Square的实现细节可能与Circle有所不同，因此它们将不得不重写某些方法来提供Move功能。

在简单的示例中，这通常可以归结为一个公共Move，该Move仅将所有工作委派给私有虚拟ReallyDoTheMove，因此似乎有很多开销，却没有任何好处。

但是，这不是一对一的对应关系。例如，您可以在Shape的公共API中添加一个Animate方法，并且可以通过循环调用ReallyDoTheMove来实现该方法。您最终得到两个都依赖于一个私有抽象方法的公共非虚拟方法API。您的圆和正方形不需要做任何额外的工作，也不需要重写Animate。

基类定义了使用者使用的公共接口，并且定义了实现那些公共方法所需的原始操作的接口。派生类型负责提供这些原始操作的实现。

我不知道C＃和C ++之间的任何差异都会改变类设计的这一方面。