C ++のプライベート仮想メソッド

C ++でプライベートメソッドを仮想化する利点は何ですか？

私はオープンソースのC ++プロジェクトでこれに気づきました：

class HTMLDocument : public Document, public CachedResourceClient {
private:
    virtual bool childAllowed(Node*);
    virtual PassRefPtr<Element> createElement(const AtomicString& tagName, ExceptionCode&);
};

ハーブ・サッターはここでそれを非常にうまく説明しています。

ガイドライン＃2：仮想関数をプライベートにすることをお勧めします。

これにより、派生クラスが関数をオーバーライドして、必要に応じて動作をカスタマイズできます。仮想関数を派生クラスから呼び出し可能にして直接公開する必要はありません（関数を保護しただけの場合は可能です）。ポイントは、カスタマイズを可能にする仮想関数が存在することです。また、派生クラスのコード内から直接呼び出す必要がない限り、それらを非公開にする必要はありません。

メソッドが仮想の場合、プライベートであっても派生クラスでオーバーライドできます。仮想メソッドが呼び出されると、オーバーライドされたバージョンが呼び出されます。

（Prasoon Sauravが彼の回答で引用したHerb Sutterとは対照的に、C ++ FAQ Lite は、ほとんどの場合人々を混乱させるため、プライベートバーチャルを推奨しません。）

仮想メンバーを非公開と宣言するすべての呼びかけにもかかわらず、この議論は単純に水を保持しません。多くの場合、仮想関数の派生クラスのオーバーライドは、基本クラスバージョンを呼び出す必要があります。宣言されている場合はできませんprivate。

class Base
{
 private:

 int m_data;

 virtual void cleanup() { /*do something*/ }

 protected:
 Base(int idata): m_data (idata) {}

 public:

 int data() const { return m_data; }
 void set_data (int ndata) { m_data = ndata; cleanup(); }
};

class Derived: public Base
{
 private:
 void cleanup() override
 {
  // do other stuff
  Base::cleanup(); // nope, can't do it
 }
 public:
 Derived (int idata): base(idata) {}
};

基本クラスのメソッドを宣言する必要がありprotectedます。

次に、メソッドをオーバーライドする必要があるが、呼び出さないことをコメントで示すという醜い方法をとる必要があります。

class Base
{
 ...
 protected:
 // chained virtual function!
 // call in your derived version but nowhere else.
 // Use set_data instead
 virtual void cleanup() { /* do something */ }
 ...

したがって、ハーブサッターのガイドライン＃3 ...しかし、馬はとにかく納屋から出ています。

protected派生クラスの作成者が保護された内部構造を理解して適切に使用することを暗黙的に信頼しているものを宣言する場合、friend宣言がprivateメンバーに対するより深い信頼を示唆する方法と同じです。

その信頼に違反することで悪い振る舞いをするユーザー（たとえば、ドキュメントを読まないようにして「無知」のラベルが付けられている）は、自分のせいにしかできません。

更新：私は、プライベート仮想関数を使用して、この方法で仮想関数の実装を「チェーン」できると主張するフィードバックがありました。もしそうなら、是非見たいと思います。

私が使用しているC ++コンパイラでは、派生クラスの実装でプライベートベースクラスの実装を呼び出せません。

C ++委員会がこの特定のアクセスを許可するために「プライベート」を緩和した場合、私はすべてプライベート仮想関数を使用することになります。現状では、馬が盗まれた後も納屋のドアをロックすることをお勧めします。

Scott Meyersの「Effective C ++」の項目35：仮想関数の代替案を検討するときに、この概念に最初に遭遇しました。興味があるかもしれない他の人のためにスコット・メイヤーズを参照したかった。

これは、非仮想インターフェイスのイディオムを介したテンプレートメソッドパターンの一部です。公開されているメソッドは仮想ではありません。むしろ、プライベートな仮想メソッド呼び出しをラップします。その後、基本クラスはプライベート仮想関数呼び出しの前後にロジックを実行できます。

public:
  void NonVirtualCalc(...)
  {
    // Setup
    PrivateVirtualCalcCall(...);
    // Clean up
  }

これは非常に興味深いデザインパターンだと思います。追加したコントロールがどのように役立つかは、きっとわかると思います。

• なぜ仮想関数を作るのprivateですか？一番の理由は、すでにpublic対面方式を提供していることです。
• protected他の興味深いものにメソッドを使用できるように、単純に作成しないのはなぜですか？私はそれが常にあなたのデザインとベースクラスがどのように適合するかによって決まると思います。派生クラスメーカーは必要なロジックの実装に集中すべきだと私は主張します。他のすべてはすでに処理されています。また、カプセル化の問題もあります。

C ++の観点から見ると、クラスから呼び出すことができなくても、プライベート仮想メソッドをオーバーライドすることは完全に正当です。これは、上記の設計をサポートします。

私はそれらを使用して、派生クラスが基本クラスの「空白を埋める」ことを可能にし、そのような穴をエンドユーザーに公開しません。たとえば、共通のベースから派生する非常にステートフルなオブジェクトがあり、これは状態マシン全体の2/3しか実装できません（派生クラスは、テンプレート引数に応じて残りの1/3を提供し、ベースはその他の理由）。

多くのパブリックAPIを正しく機能させるために、共通の基本クラスが必要です（可変テンプレートを使用しています）が、そのオブジェクトを公開することはできません。さらに悪いことに、クレーターを純粋な仮想関数の形で「プライベート」以外のどこかにステートマシンに残すと、その子クラスの1つから派生した賢いユーザーまたは無知なユーザーが、ユーザーが決して触れてはならないメソッドをオーバーライドできるようになります。そこで、ステートマシンの「頭脳」をPRIVATE仮想関数に入れました。次に、基本クラスの直接の子が非仮想オーバーライドの空白を埋め、ユーザーはステートマシンの混乱を心配することなく、結果のオブジェクトを安全に使用したり、独自の派生クラスを作成したりできます。

パブリック仮想メソッドを持ってはいけないという議論については、私はBSと言います。ユーザーは、パブリック仮想と同じくらい簡単にプライベート仮想を不適切にオーバーライドできます。結局、新しいクラスを定義しています。公衆が特定のAPIを変更してはならない場合は、公にアクセス可能なオブジェクトで仮想AT ALLにしないでください。