変更しないものとしてマークを付けることができると、デザインの観点からしばしば役立ちます。同様に、constはコンパイラガードを提供し、状態が変化してはならないことfinalを示します。これを使用して、継承階層の下位で動作を変更しないことを示すことができます。
例
車両がプレイヤーをある場所から別の場所に連れて行くビデオゲームを考えてみましょう。すべての車両は、出発前に有効な場所に移動していることを確認する必要があります（その場所の基地が破壊されていないなど）。車両に関係なくこのチェックが行われることを保証するために、非仮想インターフェースイディオム（NVI）を使用して開始できます。
class Vehicle
{
public:
virtual ~Vehicle {}
bool transport(const Location& location)
{
// Mandatory check performed for all vehicle types. We could potentially
// throw or assert here instead of returning true/false depending on the
// exceptional level of the behavior (whether it is a truly exceptional
// control flow resulting from external input errors or whether it's
// simply a bug for the assert approach).
if (valid_location(location))
return travel_to(location);
// If the location is not valid, no vehicle type can go there.
return false;
}
private:
// Overridden by vehicle types. Note that private access here
// does not prevent derived, nonfriends from being able to override
// this function.
virtual bool travel_to(const Location& location) = 0;
};
今、私たちのゲームには飛行車両があり、すべての飛行車両が必要とする共通点は、離陸前に格納庫内の安全検査チェックを通過する必要があるということです。
ここではfinal、すべての飛行車両がこのような検査を通過することを保証し、飛行車両のこの設計要件を伝えるために使用できます。
class FlyingVehicle: public Vehicle
{
private:
bool travel_to(const Location& location) final
{
// Mandatory check performed for all flying vehicle types.
if (safety_inspection())
return fly_to(location);
// If the safety inspection fails for a flying vehicle,
// it will not be allowed to fly to the location.
return false;
}
// Overridden by flying vehicle types.
virtual void safety_inspection() const = 0;
virtual void fly_to(const Location& location) = 0;
};
finalこのように使用することで、非仮想インターフェイスのイディオムの柔軟性を効果的に拡張して、継承階層の下で均一な動作を（たとえ後から考えても、壊れやすい基本クラスの問題に対抗して）仮想関数自体に提供できます。さらに、私たちは自分の部屋を購入して、存在するすべての飛行車両の実装を変更することなく、後付けとしてすべての飛行車両タイプに影響する中心的な変更を行います。
これは、の使用例の1つfinalです。仮想メンバー関数がこれ以上オーバーライドされても意味がないコンテキストが発生します。これを行うと、設計が不安定になり、設計要件に違反する可能性があります。
これfinalは、設計/アーキテクチャの観点から見ると便利です。
また、オプティマイザが仮想関数呼び出しを仮想化解除できるようにするこの設計情報を提供するので、オプティマイザの観点からも役立ちます（動的ディスパッチのオーバーヘッドがなくなり、多くの場合、呼び出し側と呼び出し先の間の最適化の障壁がなくなります）。
質問
コメントから：
なぜfinalとvirtualが同時に使用されるのですか？
これは、両方としての機能を宣言するために階層のルートに基本クラスの意味がないvirtualとfinal。コンパイラと人間の読者の両方が不必要なフープを飛び越えなければならないので、それは私にはかなりばかげているように見えますvirtual。ただし、サブクラスは次のような仮想メンバー関数を継承します。
struct Foo
{
virtual ~Foo() {}
virtual void f() = 0;
};
struct Bar: Foo
{
/*implicitly virtual*/ void f() final {...}
};
この場合、Bar::fvirtualキーワードを明示的に使用するかどうかBar::fは仮想関数です。virtualキーワードは、この場合には、オプションとなります。したがって、それが仮想関数であっても、Bar::fとして指定することは意味があるかもしれませんfinal（仮想関数にのみ使用finalできます）。
そして、一部の人々は、様式的に、それBar::fが仮想であることを明示的に示すことを好むかもしれません。
struct Bar: Foo
{
virtual void f() final {...}
};
私にとって、このコンテキストで同じ関数にvirtualとfinal指定子の両方を使用するのは一種の冗長です（同様にvirtualおよびoverride）。ただし、この場合はスタイルの問題です。他のリンケージ修飾子がないオプションのオプションであるにもかかわらず、外部リンケージのある関数宣言にvirtual使用するのと同じように、それがここで何か価値のあるものを伝えると感じる人もいるかもしれませんextern。