お茶漬けびより

"あなたに教わったことを、噛んでいるのですよ" 五等分の花嫁 7巻 「最後の試験が五月の場合」より

拡張式 Factory Method

デザインパターン C++

f:id:pickles-ochazuke:20170715173147j:plain

ナッツ食べてます。そこそこおいしいです。

前回、FactoryMethod を作りましたが、今回は、それを改造します。

pickles-ochazuke.hatenablog.com

基本的な FactoryMethod だと、新しいクラスを作ったときに毎度 FactoryMethod 側も新しいクラス用の処理を追加しないといけません。そこで、新しいクラスへの対応を実行中に行えるようにします。

概要

大まかに書くと、抽象基本クラスを継承した新しいクラス側に、"自身のオブジェクトを作成し、それを返す" コールバック関数を作ります。そのコールバック関数と key となる文字列を FactoryMethod に渡し、FactoryMethod 側は、その関係を覚えておきます。実際にオブジェクトが必要になったときは、key となる文字列を渡すことで、それに対応したコールバック関数が FactoryMethod 内で呼ばれ、作成されたオブジェクトが返ってくる。という感じです。

図にすると以下のような感じでしょうか。

f:id:pickles-ochazuke:20170715194958p:plain

上記は、Callback の登録のみしか書いていませんが、削除もできたほうがいいので、実装時には削除用の関数も作ります。

FactoryClass

まずシーケンス図にあった FactoryClass のヘッダは以下のとおりです。 クラス名は、前回の続きなので SlimeFactory となっています。 また、SlimeFactory で作られるオブジェクトは、すべて抽象基本クラスの ISlime を継承しています。

#pragma once
#include <string>
#include <map>
#include <functional>
#include "ISlime.h"

class SlimeFactory
{
public:
    using DoMakeCallback = std::function<ISlime*()>;

    SlimeFactory()  = delete;
    ~SlimeFactory() = delete;
    static void RegisterSlime(const std::string& type, DoMakeCallback cb);
    static void UnregisterSlime(const std::string& type);
    static ISlime* DoMakeSlime(const std::string& type);

private:
    using CallbackMap = std::map<std::string, DoMakeCallback>;
    static CallbackMap DoMakes_;

};

上から順番に見ていきます。まず、using DoMakeCallback = std::function<ISlime*()> ですが、 これは、コールバック関数の型を定義しています。using DoMakeCallback は書くのを楽にしているだけで、std::function<ISlime*()> が大事です。これが、登録するコールバック関数の型になります。登録したいクラスは、コールバック関数を作るとき、この型（ISlime*()）を守る必要があります。std::function は、関数ポインタ用のクラスだと思っておけば問題ないです。

コンストラクタとデストラクタは、今回必要ないので delete しています。実際に FactoryClass を作るときは、1つしか作られないようにシングルトンにするといいでしょう。

static void RegisterSlime(const std::string& type, DoMakeCallback cb) は、コールバック関数を登録するための関数です。登録したいコールバック関数があるとき、この関数を呼び出して、引数に key となる文字列とコールバック関数を渡してやります。

static void UnregisterSlime(const std::string& type) は、先ほどとは逆で、登録済みのコールバック関数を削除する関数です。使うときは、登録したときに渡した文字列と同じ文字列を引数に渡すだけです。

static ISlime* DoMakeSlime(const std::string& type) は、オブジェクトが必要になったときに呼びます。引数に登録時の文字列を渡してやることで、生成されたオブジェクトが返ってきます。

using CallbackMap = std::map<std::string, DoMakeCallback> は、これも型を定義しているだけです。std::map<std::string, DoMakeCallback> は、コールバック関数を登録するための型になります。std::string が key となり、DoMakeCallback が登録されたコールバック関数です。

最後に、static CallbackMap DoMakes_ ですが、これは、コールバック関数が登録される場所になります。

次に、ソースファイルを見ていきます。

#include "HealSlime.h"
#include <iostream>

// インスタンス化
SlimeFactory::CallbackMap SlimeFactory::DoMakes_;

void SlimeFactory::RegisterSlime(const std::string& type, DoMakeCallback cb)
{
    DoMakes_[type] = cb;
}

void SlimeFactory::UnregisterSlime(const std::string& type)
{
    DoMakes_.erase(type);
}

ISlime* SlimeFactory::DoMakeSlime(const std::string& type)
{
    if (type == "Slime") {
        return new Slime();
    }
    else if (type == "SheSlime") {
        return new SheSlime();
    }
    else if (type == "HealSlime") {
        return new HealSlime();
    }

    CallbackMap::iterator it = DoMakes_.find(type);
    if (it != DoMakes_.end()) {
        if (!it->second) { std::cout << "呼び出せない" << std::endl; return nullptr; }
        return (it->second)();
    }

    return nullptr;
}

上から順番に見ていきましょう。 まずは、SlimeFactory::CallbackMap SlimeFactory::DoMakes_ で static の変数をインスタンス化してやります。

RegisterSlime(const std::string& type, DoMakeCallback cb) は、登録なので、登録用の変数 DoMakes_ にコールバック関数を登録しています。

UnregisterSlime(const std::string& type) は、削除なので、type を元に DoMakes_ に登録されているコールバック関数を削除しています。

DoMakeSlime(const std::string& type) は、type を元に作成すべきオブジェクトを決め、作成し、そのオブジェクトを返します。
Slime, SheSlime, HealSlime は、前回作成した内容です。そこを抜けると type と関連するコールバック関数があるか探します（CallbackMap::iterator it = DoMakes_.find(type);）。見つかれば、そのコールバック関数が呼べるか確認（if (it != DoMakes_.end())）し、問題なければ、呼び出して、返ってきたオブジェクトをそのまま返します（return (it->second)()）。

以上が拡張式の FactoryMethod になります。

登録するためのコールバック関数の中身は、以下のように書きます。

static ISlime * DoMakeMyself()
{
    return new MySlime();
}

このメソッドを RegisterSlime の第二引数に渡してやれば、DoMakes_ に登録されます。

実行

実際に使うときは、以下のように使います。

 std::function<ISlime*()> func = MySlime::DoMakeMyself;
    SlimeFactory::RegisterSlime("MySlime", func);

    ISlime* slime = SlimeFactory::DoMakeSlime("MySlime");

結果は、以下です。

ぼくが考えた最強のスライム が現れた！

続行するには何かキーを押してください . . .

以上のように、新しいクラスを作ったときは、FactoryClass 側で何も追加する必要なく、対応することが出来ました。

おわり

実際に作ってみると、することは難しそうだけど、作ってみたら簡単だった。ように感じました。コールバック関数の登録も削除も一行で済み、呼び出すときもfindで探して、呼び出すだけですので。

今回の難しいところは、拡張式の FactoryMethod の作り方よりも、関数ポインタ、std::map、を理解しているかどうかだと思います。さらに言ってしまえば、std::map は今回採用しているだけなので、何か key を渡されたときに、それに関係する関数ポインタを返せるならどう作ってもいいわけです。なので、今回一番重要なのは、関数ポインタを理解しているかどうかなのだと思いました。

最後に、コードと参考資料を載せておきます。

github.com

C++のためのAPIデザイン

C++のためのAPIデザイン

Factory Method を使って、スライム属を作る

デザインパターン C++

Factroy Method をドラクエのスライムで表現してみる記事。

Factory Method とは

オブジェクト指向における再利用のためのデザインパターンの一つです。そのデザインパターンの中でも生成に関するパターンの一つ。

このパターンによって、オブジェクト型を指定せずにオブジェクトを生成できるようになります。
簡単に説明すると、関数内でコンストラクタを呼び、生成したオブジェクトを返すのがこのパターンの基本になります。 これに継承を組み合わせることで、動的にオブジェクトを生成することができるようになります。

で、この FactoryMethod を使って、いろんなスライムを作るというのが今回のお話です。 ちなみに、抽象基本クラスを分かっておく必要があるので、分からない方は、調べるか、以下を参考にしてみるといいでしょう。

pickles-ochazuke.hatenablog.com

全体イメージ

f:id:pickles-ochazuke:20170714010327p:plain

UML 図を初めて書いたので、間違っているところがあるかも……。

まずは大きく４つに分けて、ISlime, Slime, SheSlime, HealSlime, Status。一つずつ簡単に説明します。

Status

これは、スライムのステータスを表します。日本の（RPG）ゲームでいうステータスと英語の Status は、意味が異なるようなのだけど、 ここでは深く考えないようにします。中身は、見てみると何となく分かると思うのだけど、名前（name_）、HP（hp_）、MP（mp_）、攻撃力（attack_）、防御力（defense_）、経験値（exp_）、ゴールド（gold_）が入っている。モンスター（今回は、スライム属のみ）共通のステータスとなります。

ISlime

スライム属の抽象基本クラスです。ISlime の I は、Interface の I 。
スライム属に属するクラスは、これを継承します。これによってあとで作る FactoryMethod は、一つの関数で動的にオブジェクトを作れるようになります。name(), hp(), mp(), attack(), defense(), exp(), gold()は、get 関数で特に意味はなくて、status_ にアクセスする手段を用意しているだけ。あと、コンストラクタ、デストラクタは、実際にはあるのだけど、書いてないです。これは、Slime, SheSlime, HealSlime 共通。

Talk(), Skill() は、それぞれ純粋仮想関数。継承先は、この二つの処理を実装する必要があります。

ViewInformation() は、オブジェクトのステータスを出力します。

Slime

スライムを表すクラス。Talk(), Skill() をオーバライドしています（あとデストラクタも）。ここら辺は、実行したときにちゃんと Slime のクラスが作られているか分かるようにしているだけなので、実装内容は何でもいいです。

SheSlime

ベススライムを表すクラス。外国だと SheSlime と言うみたいです。内部の説明は、Slime と同じ。もちろん実装内容は、区別できるようにしてあります。

HealSlime

ホイミスライムを表すクラス。これも Slime と同じ。

以上のスライムクラスを使って、FactoryMethod を作ります。

FactoryMethod

まずは、クラス図を

f:id:pickles-ochazuke:20170714013033p:plain

FactroyMethod を実装するのは、SlimeFactory というクラス。このクラスは、今回、コンストラクタもデストラクタも必要ないので、delete しています。DoMakeSlime() という関数が FactoryMethod になります。

実際は、FactoryMethod を実装しているクラス内でオブジェクトの管理やシングルトンパターンを実装するようだけど、簡単にするためにそれらは実装していません。
というか生成と管理を一つのクラスで任せるものなのかどうか分からないです……。別々にしても良さそうだけど、どうなんだろう？

クラス図の"関連"を表す矢印の使い方が正しいのか自信はないのだけど、これらをインクルードする必要があるので、"関連"としています。
ただ、ヘッダ（SlimeFactory.h）でインクルードするのは、ISlime のみで、他はソースファイル（SlimeFactroy.cpp）でインクルードしています。

実装

実装内容は以下のようになっています。まずは、ヘッダファイル。

#pragma once
#include <string>
#include "ISlime.h"

class SlimeFactory
{
public:
    SlimeFactory() = delete; 
    virtual ~SlimeFactory() = delete;

    static ISlime* DoMakeSlime(const std::string& type);
};

スライム属のクラスの内、インクルードしているのは、 “ISlime.h” のみで、他のクラスはここで知る必要はないです。

コンストラクタとデストラクタは必要なかったので、delete しています。デストラクタを仮想にしているけど必要ないです……。

DoMakeSlime(const std::string& type) が先に書いたように FactroyMethod になります。type の値を見て、どのオブジェクトを作るかを決めています。作りたいオブジェクトが分かるなら文字列でも enum 型でもただの値でもいいです。たぶん enum 型が一番扱いやすいです。

次にソースファイル。

#include "SlimeFactory.h"
#include "Slime.h"
#include "SheSlime.h"
#include "HealSlime.h"

ISlime* SlimeFactory::DoMakeSlime(const std::string& type)
{
    if (type == "Slime") {
        return new Slime();
    }
    else if (type == "SheSlime") {
        return new SheSlime();
    }
    else if (type == "HealSlime") {
        return new HealSlime();
    }

    return nullptr;
}

こちらでは、実際にオブジェクトを作るために型を知る必要があるので、Slime.h, SheSlime.h, HealSlime.h をインクルードしています。

DoMakeSlime の処理は、とても簡単で type の中身を見て、条件式で判定して、その中のオブジェクト生成処理を実行し、そのオブジェクトを返すだけです。型の異なるオブジェクトを返せるのは、継承元が全て同じ ISlime だから。

戻り値の型を void* にすれば、継承元が異なる型を返すようにすることも出来るけど、危険だろうし、扱いづらい。それなら抽象基本クラスごとに関数を分けた方がいいと思います。

次は、実際に使うときのコードとその結果を載せます。

実行

main.cpp 内は、以下のようになっています。

#include <iostream>
#include "ISlime.h"
#include "SlimeFactory.h"

int main(void)
{
    ISlime* slime = SlimeFactory::DoMakeSlime("Slime");
    slime->Skill();
    delete slime;

    slime = SlimeFactory::DoMakeSlime("SheSlime");
    slime->Skill();
    slime->ViewInformation();
    delete slime;

    slime = SlimeFactory::DoMakeSlime("HealSlime");
    slime->Skill();
    delete slime;

    slime = SlimeFactory::DoMakeSlime("");
    if (!slime) {
        std::cout << "スライムの生成に失敗した！" << std::endl;
        std::cout << std::endl;
    }
    else {
        slime->Skill();
        delete slime;
    }

    return 0;
}

実行する側は、FactoryMethod のクラスと、抽象基本クラスだけを知るだけで使うことができます。もちろん、継承先にしかない機能を使う場合は、そのクラスのヘッダファイルをインクルードする必要があります。

実行結果は、以下のようになります。

スラりん が現れた！

スラりん のスキル発動！ 逃げ出す！
しかし、逃げられなかった！

へんじがない。ただのスラりんのようだ。

スラみ のスキル発動！ メラ！
しかし、MP が足りない！

class SheSlime の情報を表示します ========
スラみ
8
3
10
12
3
1
===============================

ホイミン のスキル発動！ ホイミ！
ホイミン に 30 の回復！

スライムの生成に失敗した！

続行するには何かキーを押してください . . .

おわり

以上、FactoryMethod の基本を書いてみました。上手くクラスを抽象化できれば、FactoryMethod が有効活用できそうです。FactoryMethod を扱うことよりもクラスの抽象化をどうするかの方が難しいのかもしれないですね。

作成したオブジェクトを FactroyMethod の内部（今回だと SlimeFactory）で持つか、作成を依頼してきた側（main関数）に任せるかは、その時々で変わりそう。

最後に、今回のコードを以下に上げておきます。

github.com

参考にした資料は以下です。

C++のためのAPIデザイン

C++のためのAPIデザイン

オブジェクト指向における再利用のためのデザインパターン

オブジェクト指向における再利用のためのデザインパターン

Visual Studio で 動的ライブラリ（DLL）を利用する

C++

f:id:pickles-ochazuke:20170705153431j:plain

前回は、作成するところまで行いました。
今回は、実際に使ってみたいと思います。

pickles-ochazuke.hatenablog.com

DLL を使うプロジェクトを作成

とくに変わったところはないです。いつも通り作っちゃってください。自分は、空のプロジェクトで作成しました。プロジェクト名は、Project3です。ついでに main 関数を書くためにソースファイル（main.cpp）を作っておきましょう。

DLL を使うための準備

さて、まずは DLL を使えるようにしないといけません。ざっくり手順を書きますと

  1. ソリューションに DLL のプロジェクトを追加（プロジェクトは、前回作成済み）
  2. 使う側に DLL の参照を追加する
  3. DLL のヘッダファイルがあるディレクトリを追加する

1. ソリューションに DLL のプロジェクトを追加

ソリューションエクスプローラに表示されているソリューションを右クリックして、追加 > 既存のプロジェクト を選択します。

f:id:pickles-ochazuke:20170705164854p:plain

するとエクスプローラが開くので、追加したい DLL のプロジェクトを選びます。ここでは、前回作成したプロジェクト（DLLTest.vcxproj）を選びました。これでソリューションエクスプローラに、先ほど選んだプロジェクトが表示されていると思います。これで追加完了です。

f:id:pickles-ochazuke:20170705165339p:plain

2. 使う側にDLL の参照を追加する

次に、今回作成したプロジェクト（Project3）に参照を追加します。画像で見ていただくと分かりやすいと思いますが、ソリューションエクスプローラに表示されている、Project3 の下に参照があると思います。ここを右クリックして、参照の追加を選びます。 f:id:pickles-ochazuke:20170705165916p:plain

で、前回作成したプロジェクト名が表示されていると思うので、それにチェックを入れます。

f:id:pickles-ochazuke:20170705170036p:plain

3. DLL のヘッダファイルがあるディレクトリを追加する

Project3 を右クリックして、一番下にあるプロパティを選択します。で、構成プロパティ > C/C++ と選び、追加のインクルードディレクトリに追加したい DLL のヘッダファイルがあるディレクトリを選びます。前回作成した DLL の場合、DLLTest.h があるディレクトリを選びます。これで準備完了です。

f:id:pickles-ochazuke:20170705170257p:plain

f:id:pickles-ochazuke:20170705170143p:plain

DLL を使う

実際に使ってみます。手順 1 ですでにソースファイル（main.cpp）を作ってあると思うので、そこに書いていきましょう。
以下のように書きました。

#include <iostream>
#include "../DLLTest/DLLTest.h"

int main()
{
    DLLTest::HelloWorld hello;
    DLLTest::HelloWorld::hello();

    hello.world();
    std::cout << hello.huga << std::endl;

    return 0;
}

DLLTest.h のインクルード場所は、環境によって異なると思いますので、注意してください。ビルドをして通ったら、実行してみましょう。あ、実行の前に、メニュー > プロジェクト > "プロジェクト名"のプロパティ を選び、構成プロパティ > リンカー > システム を選びます。で、サブシステムという欄があるので、コンソールを選び、OK を押します。

f:id:pickles-ochazuke:20170705170722p:plain

実行すると同じであれば、以下のように表示されると思います。

f:id:pickles-ochazuke:20170705171212p:plain

おわり

以上が DLL の使い方になります。プロジェクトとヘッダファイルが必要になるので、どこか共通の場所を作っておくと良いかもしれません。どう管理するといいんだろう……。

以下を参考にしました。

https://msdn.microsoft.com/ja-jp/library/ms235636.aspx

Visual Studio で 動的ライブラリ（DLL）を作成する

C++

f:id:pickles-ochazuke:20170705153246j:plain

自分へのメモ書き（上の画像に意味はないです）。

ライブラリを自分で作ったことがなかったので、ちょいと作ってみることに。
Visual Studio は 2017 です。あと C++ で書きます。

DLL プロジェクトの作成

まず、いつも通り Visual Studio を起動して、新しいプロジェクトを作成します。
選ぶプロジェクトの種類ですが、Win32 コンソールアプリケーション を選びます。
で、名前はてきとうで構いません。
簡単で打ち間違いにくい名前にするといいかもしれません。ここでは、DLLTest にしました。

f:id:pickles-ochazuke:20170704231404p:plain

OK > 次へ > と進み、アプリケーションの種類では、DLL を選びます。
他は、何もいじらなくてOKです。完了を押します。

f:id:pickles-ochazuke:20170704231409p:plain

するとプロジェクトが作成され、ソリューションエクスプローラのソースファイルの下には、dllmain.cpp, DLLTest.cpp, stdafx.cpp があり、ヘッダーファイルには、stdafx.h, targetver.h があります。

f:id:pickles-ochazuke:20170704231751p:plain

それぞれ開くと、中にコメントが書かれているので、読んでおくといいかもしれません。まぁ触るのは、DLLTest.cpp だけなのですが。

DLL の実装

では、ライブラリを作っていきます。まず、ヘッダーファイルにファイルを追加します。ここは、いつも通り新しいクラスを追加するときと同じように作れば良いです。ファイル名も同じように自由です。ここでは、DLLTest.hにしました。
そして、先頭に以下を書きます。

#ifdef DLLTEST_EXPORTS
#define DLLTEST_API __declspec(dllexport)
#else
#define DLLTEST_API __declspec(dllimport)
#endif

ここで注意して欲しいのは、ifdef DLLTEST_EXPORTS です。これは、プロジェクト名によって異なりますので注意です。新しいプロジェクトを DLL として作成したときに、Visual Studio 側が勝手に定義してくれます。その名前は、プロジェクト名（全て大文字）_EXPORTS となります。今回、プロジェクト名は、DLLTest だったので、DLLTEST_EXPORTS となるわけです。

あとは、この下にいつものようにクラスを書いていきます。今回は、以下のように書いてみました。

namespace DLLTest {
    class HelloWorld {
    public:
        int huga;
        DLLTEST_API HelloWorld();
        static DLLTEST_API void hello();
        DLLTEST_API void world();
    private:
        int hoge = 0;
    };
}

各関数の手前に、DLLTEST_API があります。先頭行で書いた define です。DLLTEST_EXPORTS が定義されているので中身は、__declspec(dllexport) となるはずです。__declspec(dllexport) と __declspec(dllimport) の違いは、ちゃんと調べていないですが、DLL を作成するときは、dllexport で、 DLL を利用するときは、dllimport だと判断しています。

変数には付けなくても問題ないようです（ここら辺のことは、どこを見たら分かるんですかね……）。

次に、DLLTest.cpp に書いていきます。全文を載せています。

#include "stdafx.h"
#include "DLLTest.h"
#include "iostream"

namespace DLLTest {
    HelloWorld::HelloWorld()
        : hoge(32)
    {  
        std::cout << "HelloWorld " << hoge << std::endl;
    }

    void HelloWorld::HelloWorld::hello()
    {
        std::cout << "Hello";
        return;
    }

    void HelloWorld::HelloWorld::world()
    {
        std::cout << "World" << std::endl;
        return;
    }
}

こちらは、とくに変わらずいつも通りに書いてしまえば問題ありません。気をつけるのは、stdafx.h は一番最初にインクルードする必要があることです。原因はよく分かっていないですが、他のインクルードの後だと、ビルドが通りませんでした。

ビルドをして成功したら、DLLTest のフォルダ下にある Debug フォルダに DLLTest.dll があると思います。

おわり

以上で DLL の作成は完了です。まだまだ何となくで作っていますが、少しずつ理解を深めていこうと思います。そのときに分かったことがあれば、また記事にしたいですね。何か参考になりそうな資料を教えていただければ幸いです。

次回は、作成した DLL を使ってみたいと思います。

pickles-ochazuke.hatenablog.com

以下を参考にしました。

https://msdn.microsoft.com/ja-jp/library/ms235636.aspx
https://msdn.microsoft.com/ja-jp/library/3y1sfaz2.aspx

抽象基本クラス（Abstract Base Class : ABC）の復習

C++

ファクトリーメソッドを復習しようと思ったら、抽象基本クラスの復習をする羽目になったので、 調べて学んだことをメモ書きします。

抽象クラスとは

概念的なもの。このクラスから実態を持つことは出来ないが、抽象クラス型へのポインタと参照は使用できる。だそうです。

抽象クラス (C++)

実態を持たないので、継承しないと意味がありません。なので、抽象基本クラスとも言うそうです（自分が読んだ本には、抽象基本クラスと書いてあった）。今後、抽象基本クラスは ABC(Abstract Base Class) と表記します。

じゃあ、どういうものが ABC かというと、純粋仮想メンバ関数を持つクラスのことを ABC といいます。純粋仮想メンバ関数というのは、以下の様なものです。

virtual void Method() = 0;

純粋仮想メンバは、継承先で必ずオーバーライドしないといけません。つまり継承先で必ず実装しないといけません。ですが、ABC 側で実装をしてはいけないという意味ではありません。Method() を .cpp ファイルで実装するとコンパイルは通り、呼ぶことが可能です。

ABC は実態を持つことは出来ませんが、ABC 型へのポインタを作ることが可能です。
このポインタを使って、ABC を継承した様々なクラスのインスタンスへのポインタを入れることが出来ます。つまり、以下のように書きます。

IBase *instance = new Derived();

IBase は、ABC です。Derived は、 IBase を継承したクラスです。
instance->method() のように使えば、継承したインスタンスを呼ぶことが出来ます。上記は、Derived のみですが、他に IBase を継承したクラスがあれば、同じように使うことが出来ます。

コンストラクタ、デストラクタ

コンストラクタを仮想化することは出来ませんが、デストラクタは可能です。 つまり以下のように書けます。

virtual ~IBase();

これは、ABC で必ず必要になります。ABC は、実態を持つことはないので、必ず継承されて使われます。しかし、書かなくてもコンパイルは通ります。このときコンパイラは、デフォルトデストラクタを作成しますが、この状態で ABC を継承した Derived 型のポインタを delete すると、大変なことが起こります。コードで示すと以下のようになります（コンパイルは通らないかもしれません……）。

// 抽象基本クラス
class IBase
{
public:
    virtual void Method() = 0;
};
// 抽象基本クラスを継承したクラス
class Derived : public IBase
{
public:
    ~Derived(){};
    void Method() {};
};

int main()
{
    IBase *instance = new Derived();
    instance->Method();
    delete instance;
    
    return 0;
}

このとき、delete で呼ばれるデストラクタは、IBase のデフォルトデストラクタです。継承先のデストラクタは呼ばれません。どうしてかは詳しく説明できないですが、IBase のデストラクタが実態を持っていることが原因であることは分かると思います。 ですので、抽象基本クラスを作るときは、必ずデストラクタに virtual を付けるように気を付けましょう。

キーワード：override

デストラクタには virtual を付けるように気をつけましょうと言いましたが、このミスをコンパイル時に見つける方法があります。それが、override 指定子です。
こいつを付けることで、コンパイラに「今からオーバーライドするよ」と教えることが出来ます。つまり以下のようになります。

// 抽象基本クラスを継承したクラス
class Derived : public IBase
{
public:
    ~Derived() override {};
    void Method() {};
};

と ~Derived() の後に override を付けることで、コンパイル時にエラーが発生するようになります（Visual Studio 2017 だとコンパイルする前に赤い波線が出ました）。
もちろんデストラクタだけでなく、メソッドにも付けることが可能です。オーバーライドをするときには、必ず override を付けるようにしましょう。

override 指定子

キーワード：final

今度は、逆にオーバーライドをして欲しくないときの対処法です。override と同じようにメソッドの後ろに final を付けます。以下のようになります。

virtual int value() final { return value_; };

このように書くことで、継承先がオーバーライドをしようとすると、コンパイラはエラーを発します。処理が今後変わることがないときは、 final を付けるようにしましょう。

final 指定子

キーワード：delete

最後に delete を紹介します。これは、delete 演算子ではありません。何と言うのかちょっと調べただけでは分からないですが、このキーワードを使うことで、メソッドやコンストラクタ、デストラクタを削除することが出来ます。 以下のように書きます。

public:
IBase() = delete;

public 側で書くことをお勧めします。これはコンパイラが delete であるかどうかよりもアクセスの可否を先に見るためです。private で delete されたメソッドをユーザが使おうとすると メソッドが private であることだけをエラーとして吐くそうです。また他にも利点があるのですが、ここでのメインの話ではないので省きます。詳細は、Effective Modern C++ の項目 11 を見てください。

Effective Modern C++ ―C++11/14プログラムを進化させる42項目

Effective Modern C++ ―C++11/14プログラムを進化させる42項目

おわり

以上、抽象基本クラスの復習でした。 C++11 から使えるようになったキーワードを混ぜることで、安全に継承をすることが出来るようになりそうです。

ここで記載したコードは、以下に上げています。

github.com

最後に、参考にした（復習する羽目になった）書籍を貼っておきます。

C++のためのAPIデザイン

C++のためのAPIデザイン