ダンジョンタイプからの脱出。 型が動的に決定されるデータを処理します

SQLクエリの結果が、あらゆる種類のフィールドタイプへの無限のタイプ変換を意味する場合。 コードがboost ::バリアント型によるオーバーロードの巨大な列挙を持つあいまいなロジックで満たされている場合。 RPCプロトコルに従って任意の型の引数を受け入れる方法がわからない場合。 次に、C ++では動的型付けエミュレーションメカニズムが必要です。 拡張可能でユーザーフレンドリーで、明確なAPIを作成します。 事前定義されたタイプのリストを必要とせず、基本クラスへのポインターを使用することを強制しないもの。 このようなメカニズムがあります-ダブルディスパッチが役立ちます！



デュアルディスパッチとは何か、C ++でそれを正しく、効率的かつ明確に準備する方法を理解するには、まずそれが必要な理由を説明し、このソリューションへのすべての進化の道筋をたどる必要があります。 この説明がなければ、初心者の開発者は読書の終わりまでに夢中になり、経験豊富な開発者はおそらく自分の団体にdrれ、間違った結論を導き出します。 したがって、最初から始めます-動的型付けの基本とC ++で必要なものから。

C ++での動的型付け

C ++では、入力は静的であるため、コンパイル段階で標準操作を操作する際のエラーを追跡できます。 原則として、ケースの90％で、操作の結果のタイプ、またはすべての可能な値の基本クラスのいずれかを事前に知っています。 ただし、操作の結果としての値のタイプが事前にわからず、実行段階で計算される問題のクラスがあります。 典型的な例は、データベースへのクエリの結果です。SQLクエリの実行結果として、クエリの完了後に適切な型に展開する必要がある一連の値を取得します。



別の例は、RPCプロトコルを介してリモート関数を呼び出した結果です。結果は実行時に認識されます。特に、RPCプロトコルの中間APIを提供するという一般的な問題を解決する場合、タスクを設定する段階で戻り値のセットを常に予測できるとは限りません。 実行時に計算するのがより便利な型システムで機能する潜在的に拡張可能な機能、たとえば同じ関数の引数やSQLクエリパラメーターについては、すべて同じことが当てはまります。これらは一般的に一般化するのがより便利ですが、同時に、何らかの方法で保存する必要があります送信します。



基本クラスとその子孫を使用した古典的なソリューションから始めます。

操作の結果としての値のタイプが事前にわからず、実行段階で計算される問題のクラスがあります。 典型的な例は、データベースクエリの結果です

基本インターフェイスと継承

C ++の基本インターフェイスを介した従来のソリューションでは、OOPパラダイムの1つであるポリモーフィズムを直接使用します。 一般クラスは区別され、通常は抽象的で、相続人でオーバーライドされる多くのメソッドを導入し、値相続人の共通の祖先の型へのリンクまたはポインタを使用して作業を実行します。

小さな例を考えてみましょう。 倉庫にさまざまな種類の商品を保管するというタスクがあるとします。 製品には、名前、倉庫内の製品カテゴリ識別子、および特定の価格を設定します。 このアプローチの基本インターフェイスクラスは次のようになります。

class IGoods { public: virtual std::string Name() const = 0; virtual int TypeID() const = 0; virtual float Price() const = 0; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

たとえば、このような商品のカテゴリをお菓子として記述する必要がある場合、クラスが必要です。たとえば、次のような特定の関数Name、TypeID、Priceを持つ基本インターフェイスの継承者です。

 class Candies : public IGoods { public: static const int TYPE_ID = 9001; Candies(std::string const& name, float price); virtual std::string Name() const override { return m_name; } virtual int TypeID() const override { return TYPE_ID; } virtual float Price() const override { return m_price; } private: std::string m_name; float m_price; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その結果、基本クラスへの参照のみで動作している間、お菓子などのあらゆる種類の商品で倉庫を埋めることができます。 つまり、倉庫は、商品の名前、価格、記事を読むだけで、その中に何が格納されているかを気にしないので、原則として、相続人クラスが実際にリンクの後ろに隠れているものを知る必要はありません。



次の利点があります。

• 拡張性が主なプラスであり、任意のライブラリで相続人を作成し、共通の権利について彼らと協力することができます。 たとえば、無限切り替えの方法を選択した場合、これは機能しません。ある時点で、システムは同じタイプのコードの異なる部分の過剰なケースバリアントで窒息します。
• 動的型付け-実際、型は実行時に設定され、タスクのロジックに応じて1つまたは別の後続クラスのインスタンスを作成できます。その結果、たとえば、JSONオブジェクトまたはSQLクエリの解析結果を入力できます。
• 視覚化-相続人のツリーを持つすべての人に非常に簡単にダイアグラムを構築する機能。基本クラスの説明は、相続人クラスの動作の自明性を暗示します。

ただし、欠点は3つしかありませんが、無視すると、C ++クラスのすべての利点が失われ、ベースインターフェイスクラスへのポインターへの作業が減るため、常に頭痛の種になります。

• 作成することは困難です-あなたが言うことは何でも、倉庫の充填、つまり、以前は未知であった後継クラスのオブジェクトの作成は、工場を通して行われなければなりません。
• 保存が難しい-組み込み型には、リンクとポインターの2つのオプションしかありません。保存できるのはポインターのみです。 もちろん、ポインタで満たされたコンテナを保存することはアプリケーションの健全性に悪影響を及ぼし、std :: shared_ptrやstd :: unique_ptrのようなスマートポインタが助けになります。 前者は非常に重く、後者の振る舞いは、明示的または暗黙的なコピーで鋭い頭痛を引き起こします。
• コピーするのは難しいです。std:: unique_ptrの場合、異なるコンテナの異なるデータを参照する予定がない場合は、std :: shared_ptrだけでなく、基本クラスのCloneメソッドにも注意する必要があります。 つまり、ユーザーを欺いてコンテナをコピーしてもC ++の通常の意味でデータがコピーされないか、プリミティブクローン操作を追加して基本クラスとそのすべての子孫をさらに複雑にします。

実際、この古典的なアプローチでは、ある場所のコードはホラー映画のように見え、通常のコンストラクターではなく、同様のモンスターが現れます。

 std::deque<std::unique_ptr<IGoods>> goods; std::unique_ptr<IGoods> result = GoodsFactory::Create<Candies>(); goods.push_back(std::move(result));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コード内の別の場所では、スマートポインターを介してコレクションの要素にアクセスすると、恐怖の形式が始まります。

 std::deque<std::unique_ptr<IGoods>> another(goods.size()); std::transform(goods.begin(), goods.end(), another.begin(), [](std::unique_ptr<IGoods>& element) { return element->Clone(); } );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これはすべてC ++の最悪の伝統に見えるため、ほとんどの場合、開発者がインターフェイスに置かれていたり、オープンソースシステムに表示されていても、そのような構成を通常と考えるのは驚くことではありません。



C ++ではすべてが本当にひどく、生成されたコピーアンドムーブコンストラクター、割り当て演算子、およびその他の人生の喜びを持つ通常のクラスではできませんか？ コンテナクラスのオブジェクト内の基本クラスへのポインタを操作するロジック全体をカプセル化できないのはなぜですか？ はい、一般的には何もありません。

データクラスの継承

今度は、基本クラスのロジックをわずかに再構築します。 基本インターフェイスを操作するすべてのロジックを通常のC ++クラスにまとめます。 基本インターフェイスクラスは抽象的でなくなり、クラスオブジェクトはコンストラクタとデストラクタの通常のロジックを受け取り、値をコピーして割り当てることができますが、最も重要なことは、マイナスを取り除くことで以前のアプローチのすべての利点を失わないことです！



言い換えると、基本クラスは、その動作が基本クラスのデータクラスから継承される後続クラスによって決定されるクラスの形式でいくつかのデータを受け取ります...紛らわしいように聞こえますか？ 次に例を見てみましょう。すべてが明らかになります。

基本クラスは、インターフェイスクラスに似たクラスの形式でデータを受け取ります。インターフェイスクラスの動作は、相続人のデータクラスによって決定されます。 継承は2つあります。データクラスも継承されます

 //      API class object { public: object(); virtual ~object(); virtual bool is_null() const; virtual std::string to_string() const; protected: //    ! class data; private: std::shared_ptr<data> m_data; }; //     API //     #include class object::data { public: data() { } virtual ~data() { } virtual bool is_null() const { return true; } virtual std::string to_string() const { return "null"; } }; //      API //      ,   object class flower : public object { public: flower(std::string const& name); virtual bool is_null() const override; virtual std::string to_string() const override; virtual std::string name() const; virtual void rename(std::string const& name); protected: //    ! class data; }; //     API //     #include class flower::data : public object::data { public: static const std::string FLOWER_UNKNOWN; data() : m_name(FLOWER_UNKNOWN) { } data(std::string const& name) : m_name(name) { } virtual bool is_null() const override { return false; } virtual std::string to_string() const override { return "flower: " + m_name; } virtual std::string name() const { return m_name; } virtual void rename(std::string const& name) { m_name = name; } private: std::string m_name; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実際、通常は相続人が多く、通常は依存ライブラリに表示されます。 次に、この楽しいデザインで何ができるのかを理解します。

 object rose = flower("rose"); object none; std::vector<object> garden; garden.push_back(std::move(rose)); garden.push_back(std::move(none)); garden[1] = flower("gladiolus"); std::for_each(garden.begin(), garden.end(), [](object const& element) { std::cout << element.to_string() << std::endl; } );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

APIクラスメソッドの実装は明らかであり、データ操作メソッドをプロキシします。 祖先のコンストラクターはデータを作成せず、nullポインターを残します。相続人のコンストラクターは、目的の型のデータの相続人で祖先のポインターを初期化します。



オブジェクトクラスの新しい子孫を作成して、文字列に変換して値をチェックするロジックに設定することを妨げるものは何もありません。 たとえば、靴のフィーチャクラスを選択できます。

 class shoes { public: shoes(long long price); virtual bool is_null() const override; virtual std::string to_string() const override; virtual long long price() const; virtual void discount(long long price); protected: class data; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

shoes ::データクラスは、flower ::データとの類推によって記述されます。 確かに、前の例から花を使って庭を操作すると、面白い結果が得られます。

 garden.push_back(shoes(100000000000LL));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、庭に1000億ルーブルの靴を残すことができます。 また、これらの靴では、不注意でつまずき、花を分類しますが、基本クラスのインターフェイスを使用した初期アプローチでも同じ問題に直面します。 庭に花だけがあることを意味する場合、std :: vectorを作成します。 どうやら、コードの作成者は、花や靴から原子炉やエジプトのピラミッドなど、未知のゴミまで、庭に何でも保管することに決めました。



典型的なロジックを持つ通常のC ++クラスを使用した動的型付けの世界へようこそ。 いいえ！ クラスをコピーすると、リンクがコピーされるだけです。 C ++クラスロジックとの最新の矛盾を修正します。

オブジェクトを変更するときにコピーする

基本オブジェクトは、元のインターフェイスがCloneメソッドで実行したこと、つまり、継承者のコンテンツをコピーすることを学習するときです。 同時に、コピーはできる限り控えめにして、データをできるだけ遅くコピーする必要があります。 この条件は、オブジェクトが大きくなり、そのコピーが明示的または暗黙的に集中するほど、より重大になります。 ここでは、オブジェクトのデータを変更する際のコピーの原則が役立ちます。



C ++での変更時コピー、またはコピーオンライト（COW）は比較的単純です。たとえば、文字列（QString）を含むどこでもCOWが使用されるQtライブラリは、これらのオブジェクトを必要なものにコピーするコストを削減します最小。



アプローチの本質は次のとおりです。

• オブジェクトは、ポインタのような補助型を介してデータを参照します。
• オブジェクトメソッドはconstおよびnon-constにできますが、次の点により、メソッドの一貫性を明確に維持することが重要です。
• オブジェクトメソッドを呼び出すとき、呼び出しは最初のアイテムから同じ補助ポインタ型を介してデータクラスメソッドを呼び出すようにプロキシされます。この目的のために、2つの演算子->がオーバーロードされ、それぞれ読みやすく、constおよびnon-constになります。

定数バージョンのoperator->オーバーロードは、必要なメソッドをデータクラスで直接呼び出し、外部クラスへの呼び出しをプロキシするだけです。

演算子->オーバーロードの非定数バージョンはもう少し興味深いもので、呼び出しがデータを変更することを意味します。 したがって、変更可能なデータを参照することを確認する必要があります。 データへのリンクが一意でない場合、つまり、コピーを延期して他の人のデータを参照する場合は、独自のデータのコピーをコピーし、目的のメソッドを呼び出して作業する必要があります。

C ++の変更時のコピーは、演算子->カプセル化されたヘルパークラスのオーバーロードにより、比較的簡単です。 const演算子と非const演算子の両方のオーバーロードをオーバーロードすることが重要です

明確にするために、このような中間参照型の最も単純化されたバージョンを取得しましょう。

 template <class data_type> class copy_on_write { public: copy_on_write(data_type* data) : m_data(data) { } data_type const* operator -> () const { return m_data.get(); } data_type* operator -> () { if (!m_data.unique()) m_data.reset(new data_type(*m_data)); return m_data.get(); } private: std::shared_ptr<data_type> m_data; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

良い方法では、コピープロセス中の例外に対してだけでなく、マルチスレッドアクセスのためにこのクラスを保護する必要がありますが、原則として、クラスはC ++でCOWを実装する基本的な考え方を伝えるのに十分単純です。 また、コピーコンストラクターでは、データクラスはデータを複製するための仮想メソッドの呼び出しを意味することを考慮する価値があります。



あとは、基本クラスオブジェクトのデータストレージを変更するだけです。

 class object { ... protected: class data; private: copy_on_write<data> m_data; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、基本クラスと互換性のある相続人のクラスの初期化、つまり実際には動的型付けを取得します。 さらに、抽象クラスへのポインターを操作しません。コンストラクター、デストラクター、コピー、および割り当てを備えた通常のC ++クラスがあり、独自の子孫を作成するためにできるだけ簡単です。 唯一の複雑な問題-プロキシメソッド（m_data->メソッド（引数）に短縮）は、呼び出し自体に加えて、スタックトレースなどの診断情報を保存できるため、呼び出しのシーケンスを維持しながらエラーの追跡と例外のスローを簡単にできるため、プラスになります例外をスローしたメソッド。



実際、データを動的に型指定するためのPimplとDoubleのディスパッチアプローチのハイブリッドがあり、実行時に型を取得します。

実際、動的データ型付けのためのPimplとDoubleディスパッチアプローチのハイブリッドを取得しました

データクラスインターフェイスを実装しますか？

データクラスを実装する場合、Pimplパターンで行われているように、外部クラスのすべてのメソッドを複製する必要はありません。 データクラスは2つの主なタスクを実行します。実装のカプセル化の詳細を隠し、外部クラスのメソッドの実装でデータへのアクセスを提供します。 get_およびset_メソッドといくつかの補助機能を作成し、外部クラスのメソッドでデータ処理を直接実行するだけで十分です。 したがって、クラスの実装とカプセル化の詳細を分離します。

ダイナミックタイピングの使用

そのため、オプションとしてリモート関数呼び出しプロトコルがあるとします。これは、データベースへのSQLクエリのパラメーター化です。 エンドユーザーにAPIを提供する一般的なメカニズムを作成する場合、実行時に引数のタイプと結果を計算します。これは、ユーザーが引数として渡すものとリモート側から受け取る結果のタイプが事前にわからないためですなぜなら、一連の呼び出しでは、次の呼び出しの引数はしばしば前の呼び出しの結果に基づいているためです。



そのような場合、基本クラスが相続人のインターフェースだけでなく、相続人データのコンテナでもある場合、C ++クラスおよびオブジェクトに関して動的型付けを必要とする機能を記述する機会が得られます。



SQLクエリの例を考えてみましょう。 要求を実行するための引数のリストは、オブジェクト型の引数の任意の数の関数に対して同じBoost.Preprocessorによって生成できます。

 //  SQL-,  db::SqlQuery  db::SqlQuery query("select * from users as u where u.type = $(usertype) and u.registered >= $(datetime) limit 10"); //    operator () db::SqlQueryResult result = query("admin", datetime::today()); //   std::for_each(result.begin(), result.end(), [](db::SqlQueryRow const& row) { //    object login = row["login"]; if (login.is_null()) std::cout << "not specified"; else std::cout << row["login"]; //   if (row["status"] == "deleted") std::cout << " (deleted)"; std::cout << std::endl; } );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

db :: SqlQuery :: operator（）への引数として、オブジェクトの任意のセットを使用できます。この場合、型を一般型オブジェクトにキャストするためのテンプレート暗黙コンストラクターを定義する必要があります。

 class object { public: template <typename value_type> object(value_type const& value); ... };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この場合、integer、boolean、floating、text、datetimeなどの形式のオブジェクトクラスからの継承者が必要です。オブジェクトのデータは、オブジェクトが対応する値で初期化されるときにオブジェクトに配置されます。 この場合、オブジェクトを任意の型で初期化することは拡張可能であり、オブジェクトを目的の型に設定するために必要なのは、boolのように、対応する特殊化を記述することだけです。

 class boolean { public: boolean(bool value) : object(value) { } ... protected: class data; friend class object; }; template<> object::object(bool value) : m_data(new boolean::data(value)) { }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで最も重要なことは異なります。クエリの結果は、実行時にデータベースのリモート側で計算されたデータを含むテーブルです。 ただし、クエリ結果のすべての行を安全に処理して、非シリアル化されていないデータではなく、非常に特定のタイプのオブジェクトを取得できます。 オブジェクトを操作したり、比較操作をオーバーロードしたり、コンストラクターとの類推によって特定の型の値を取得するためのテンプレートメソッドを作成したり、文字列に持ってきてストリームに入れたりすることができます。 オブジェクト型のオブジェクトは、通常のクラスオブジェクトとして操作できるコンテナです。



それだけでなく、必要に応じて、コンテナのロジックをオブジェクトに追加し、リクエストから返される値に対して1つのタイプだけを実行できます。 つまり、begin（）、end（）、size（）、およびoperator []メソッドをオーバーロードします。

 object result = query("admin", datetime::today()); std::for_each(result.begin(), result.end(), [](object const& row) { std::for_each(row.begin(), row.end(), [](object const& cell) { std::cout << cell.to_string() << ' '; } std::cout << std::endl; } );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

原則として、コンテナと基本クラスオブジェクトを介して何でも使用できるようにアイデアを洗練できますが、ここでは常識を忘れてはいけません。 コンパイル段階でエラーを明らかにする静的型付けの考え方は非常に優れており、動的型付けを軽率に使用できる場合はどこでも拒否することは非常に不合理です。

コンパイルの段階でエラーを検出する静的型付けのアイデアは非常に優れており、それをどこでも放棄することは非常に不合理です！

それにもかかわらず、動的型付けは、意図されたまさにその場所で非常に有用です-通常はデータストリームの解析の結果として型が動的に取得される値に対して。 さまざまな型のデータを操作するために基本クラスにカプセル化されたインターフェイスにより、通常のコンストラクターと代入演算子を使用してオブジェクトを作成およびコピーすることにより、通常のC ++オブジェクトを操作できます。コピーオンライトテクニックを使用すると、コピーを可能な限り（理想的には永久に）延期できます。



同時に、基本クラスは、さまざまなデータとコンテナーを操作するためのインターフェイスクラスです。 便宜上、比較、インデックス、数学および論理演算、フローを使用した演算など、必要なすべての演算を基本クラスに定義できます。 一般に、基本クラスへのポインターの保存、さまざまなストリームからのコピーおよびアクセスのエラーから最も保護されている、最も読みやすく論理的なコードを実装できます。 これは、このAPIが広範囲のタスク用に開発され、最初は未知の一連のタイプを操作するときに特に役立ち、一連のタイプ自体が潜在的に拡張される可能性があります。

動的型付けはあなたの責任です！

動的な入力を行うときは、非常に慎重でなければなりません。 スクリプト言語の開発者は、アルゴリズムがコンパイル段階で実行される前であっても、型をチェックするC ++、C＃、およびJavaのパワーをしばしばうらやむことを忘れないでください。 静的型付けの力を使用して、正当な場合にのみ拒否をエミュレートします！ 原則として、リモートのシリアル化されたデータサーバーに対する一般化されたAPI要求（データベース要求を含む）を実行するには、動的な型指定が必要です。

逆シリアル化の後、実行時にすでに多くの型を取得できます。 通常、データを受信するときに処理が必要なため、動的に取得されたタイプを拒否し、テキストまたはバイトストリームにシリアル化されたデータを処理することは正当化できません。 データを解析して使い慣れたC ++型を取得し、インターフェイスポインターではなく、適切に設計されたクラスの通常のオブジェクトを使用することの利便性は、貴重です。

新しい方法

, , API C++ , RPC- . , , . , , . copy-on-write operator -> const non-const , , , , . , , , . new — .



, , . , , - , . . , Pimpl, , .



API, C++. , . , , - .



API , . , , — API, .







#189.

: Qualab , ++ Parallels



ハッカーを購読する

• サイト資料
• 紙版
• iOS / iPadのハッカー
• Androidのハッカー