パブリックメンバーを仮想化または抽象化しないでください-本当にですか？

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クラスに示されているようにラップすることで、基本クラス開発者は仮想/抽象メソッドへの呼び出しをインターセプトできます。

しかし、私はこれを設計ガイドラインとしては見ていません。マイクロソフトでさえそれに従いませんStream。これを確認するためにクラスを見てください。

そのガイドラインをどう思いますか？それは理にかなっていますか、それともAPIを過度に複雑にしていると思いますか？

言って

Method1を実装し、Method2をオーバーライドする派生クラスの開発者が引数の検証を繰り返す必要があるため、パブリックメソッドを仮想または抽象にするのはアンチパターンです。

原因と結果を混同しています。すべてのオーバーライド可能なメソッドには、カスタマイズ不可能な引数検証が必要であると仮定しています。しかし、それはまったく逆です。

場合（ -より一般的な-またはカスタマイズおよび非カスタマイズ部分）1が、それはすべてのクラスの派生である固定された引数の検証を提供した方法で方法を設計したい、そしてそれは、エントリポイントは非仮想にするために理にかなっています、代わりに、内部的に呼び出されるカスタマイズ可能な部分に仮想メソッドまたは抽象メソッドを提供します。

しかし、固定されたカスタマイズ不可能な部分がないため、パブリック仮想メソッドを持つことは完全に理にかなっている例がたくさんあります：ToStringまたはEqualsまたはGetHashCode-のような標準メソッドを見て、objectクラスのデザインを改善してこれらを非公開にし、同時に仮想？そうは思いません。

または、独自のコードの観点から：基本クラスのコードが最終的に意図的にこのようになった場合

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

間のこの分離を持つMethod1とMethod1Coreだけ明らかな理由もなく、物事を複雑にします。

あなたの同僚が示唆する方法でそれを行うことは、基本クラスの実装者により多くの柔軟性を提供します。しかし、それに伴って複雑さも増しますが、これは通常、推定される利点によって正当化されません。

基本クラスの実装者の柔軟性の向上は、優先する当事者の柔軟性の低下を犠牲にすることに留意してください。彼らは、特に気にしないかもしれないいくつかの課せられた行動を得ます。彼らにとっては、物事はより厳しくなりました。これは正当化され、役立つ場合がありますが、これはすべてシナリオに依存します。

これを実装するための命名規則（私が知っている）は、パブリックインターフェイスに適切な名前を予約し、内部メソッドの名前の前に "Do"を付けることです。

1つの便利なケースは、実行されたアクションに設定と終了が必要な場合です。ストリームを開いて、オーバーライドが完了した後に閉じるように。一般に、同じ種類の初期化とファイナライズ。使用するのに有効なパターンですが、すべての抽象シナリオおよび仮想シナリオで使用することを義務付けるのは無意味です。

C ++では、これは非仮想インターフェイスパターン（NVI）と呼ばれます。（かつて、それはテンプレートメソッドと呼ばれていました。混乱を招きましたが、一部の古い記事にはその用語があります。）NVIは、それについて少なくとも数回書いたハーブサッターによって推進されています。最も初期の1つがここにあると思います。

正しく思い出せば、派生クラスは基本クラスの動作を変更するのではなく、その方法を変更するという前提があります。

たとえば、シェイプには、シェイプを再配置するMoveメソッドがあります。Shapeは移動の意味を（概念レベルで）定義するため、具体的な実装（正方形や円など）はMoveを直接オーバーライドしないでください。Squareは、位置が内部的にどのように表現されるかという点でCircleとは異なる実装詳細を持っている可能性があるため、Move機能を提供するために何らかのメソッドをオーバーライドする必要があります。

簡単な例では、これは多くの場合、すべての作業をプライベートな仮想ReallyDoTheMoveに委任するパブリックMoveに要約されるため、多くのオーバーヘッドがあり、メリットはありません。

ただし、この1対1の対応は必須ではありません。たとえば、AnimateメソッドをShapeのパブリックAPIに追加し、ReallyDoTheMoveをループで呼び出すことで実装できます。最終的に、どちらも1つのプライベート抽象メソッドに依存する2つのパブリック非仮想メソッドAPIになります。Circles and Squaresは追加の作業を行う必要がなく、Animateをオーバーライドすることもできません。

基本クラスは、コンシューマが使用するパブリックインターフェイスを定義し、これらのパブリックメソッドを実装するために必要なプリミティブ操作のインターフェイスを定義します。派生型は、これらのプリミティブ操作の実装を提供します。

クラス設計のこの側面を変更するC＃とC ++の違いを認識していません。