記事「リプレイシステムの開発（第32回）：受注システム(I)」についてのディスカッション

[MetaQuotes]

新しい記事「リプレイシステムの開発（第32回）：受注システム(I)」はパブリッシュされました:

これまで開発してきたものの中で、このシステムが最も複雑であることは、おそらく皆さんもお気づきでしょうし、最終的にはご納得いただけると思います。あとは非常に単純なことですが、取引サーバーの動作をシミュレーションするシステムを作る必要があります。取引サーバーの操作方法を正確に実装する必要性は、当然のことのように思えます。少なくとも言葉ではです。ただし、リプレイ/シミュレーションシステムのユーザーにとって、すべてがシームレスで透明なものとなるようにする必要があります。

EAが同じでなければならないと言うことは、テスターで使用するためにコンパイルし、実際の市場で使用するために再度コンパイルしないことです。プログラミングの観点からは、この方がはるかにシンプルで簡単ですが、ユーザーにとっては、EAの再コンパイルが常に必要になるという問題が生じます。そこで、最高のユーザーエクスペリエンスを保証するために、コンパイルが1回で済むEAを作成する必要があります。これが終われば、実際の市場でもテスターでも使用することができます。

デモ口座であっても、実際のマーケットでEAを使用する上で重要なのは、最も簡単に実装できることです。まずはそこから始めましょう。非常に基本的なモデルから始めます。徐々にEAを複雑化し、その機能を強化することで、最終的にはリプレイ/シミュレーションとデモ口座またはライブ口座の両方で使用できるEAを作成する予定です。まず最初にすることは、このコミュニティで公開されている他の記事で以前に説明されているコードのほとんどを拝借することです。これらの記事は私のものだから、この情報を使用することに問題はありません。システムを柔軟でモジュール化し、信頼性と堅牢性を高めるために、いくつかの変更を加えるつもりです。そうでなければ、ある時点で行き詰まりを感じ、あらゆる面でシステムのさらなる発展が不可能になるかもしれません。

この仕事は非常に複雑なので、これはほんの始まりに過ぎません。まず第1に、EAでクラス継承システムが現在どのように実装されているかを知る必要があります。以前、この連載の他の記事でも紹介しました。現在の継承図を図01に示します。

図01：現在のEAクラス継承図

この図は、これまでおこなわれてきたことに関しては非常にうまく機能していますが、本当に必要としているものにはまだほど遠いです。C_Ordersクラスをこの継承スキームに加えるのが難しいからではありません。それは、実際には、C_StudyクラスからC_Ordersクラスを派生させることで実現できますが、そのようなことはしたくありません。その理由は、OOP（オブジェクト指向プログラミング）に携わるほとんどのプログラマーが無視しがちな、非常に現実的な問題にあります。この問題はカプセル化と呼ばれています。つまり、自分の仕事に必要なことだけを知ることです。クラスの階層を作るとき、あるクラスには本当に必要な以上のことを知らせるべきではありません。私たちは常に、各クラスがそのタスクを実行するために本当に必要なことだけを知っているようなプログラミングを好むべきです。したがって、図01のダイアグラムにC_Ordersクラスを追加しながらカプセル化を維持することは、現実的に不可能です。この問題に対する最善の解決策は、図01に示すように継承ブロックからC_Terminalクラスを削除し、同じブロックに引数またはパラメータとして渡すことです。つまり、誰がどの情報を受け取るかをコントロールするのはEAのコードであり、これは情報のカプセル化を維持するのに役立ちます。

作者: Daniel Jose