オブジェクトを動的に生成するには？(いくつかのOOPネタ) - ページ 3

新しいコメント
 

ところで、ビルド1325で関数への ポインタが導入されたことをご存知でしょうか？
三角通信を適用する上で何か違いがあるのでしょうか？

MQL5です。イベントモデルの配置を簡素化するために、関数へのポインタのサポートを追加しました。

関数へのポインタを宣言するには、例えば「関数へのポインタ」型を指定します。

typedef int (*TFunc)(int,int);

これで、TFuncが型となり、関数への変数ポインタを宣言することが可能になりました。

TFunc func_ptr;

func_ptr 変数は、後で宣言するために、関数のアドレスを格納することができます。

int sub(int x,int y) { return(x-y); }
int add(int x,int y) { return(x+y); }
int neg(int x)       { return(~x);  }

func_ptr=sub;
Print(func_ptr(10,5));

func_ptr=add;
Print(func_ptr(10,5));

func_ptr=neg;           // error: neg is not of  int (int,int) type
Print(func_ptr(10));    // error: there should be two parameters

関数へのポインタは、パラメータとして格納し、渡すことができます。非静的なクラスメソッドへのポインタは取得できない．

 
MT4でも関数 ポインタの使い方が実装されているかどうかはわかりません。もしそうなら、もちろん、そのようなポインタを配列で管理できるのであれば、クラスポインタで可能なので、そのようにすることもできます。
 

はMT5用で、私が見た限りではまだメソッド用ではなく、関数だけです。

とにかく、ベースクラス内でサードパーティーの能力をどのように定義するのか、例えばトレンドラインと コンテナの文脈では、3番目のオブジェクトはどこにあるのか、まだ理解できていない。

でも、もう一度読み直してみます。

 
OOやMQL5と連携したイベント モデルについて理解が足りないのは、イベントをどのようにディスパッチするのが正しいのか、ということです。
つまり、誰が（どのクラスが）どのような（イベントを）取得するのか、どこでどのように決定するのか、ということです。
一番上のディスパッチャ、つまり言語ネイティブなもの、つまり言語 ::OnChartEvent は、プロジェクトの最上位クラスで一度だけ書かれることは明らかです。

では、ここから、異なるオブジェクトにイベントをディスパッチする正しい方法とは何でしょうか？
ディスパッチ・イベント・クラスが必要なのか？if文に基づく:OnChartEventの中だけで行うべきでしょうか？
 
OK、わかったような気がします。手続き型からOop型になると、コンセプトのずれが本当に問題になりますね。
つまり、CTradeの存在を知らなくても、CTrendLineのプライスクロスをイベントによってCTrade継承 オブジェクトに通知する方法ということでよろしいでしょうか？
 
Amir Yacoby:
OOやMQL5と連携したイベントモデルについて理解が足りないのは、イベントをどのようにディスパッチするのが正しいのか、ということです。
つまり、誰が（どのクラスが）どのような（イベントを）取得するのか、どこでどのように決定するのか、ということです。
一番上のディスパッチャ、つまり言語ネイティブなもの、つまり言語 ::OnChartEvent は、プロジェクトの最上位クラスで一度だけ書かれることは明らかです。

では、ここから、異なるオブジェクトにイベントをディスパッチする正しい方法とは何でしょうか？
ディスパッチ・イベント・クラスが必要なのか？if文に基づく::OnChartEventの中だけで行うべきでしょうか？
これは全く問題ありません。OOPは自然界の原理原則に基づいています。地球はあなたを養ってはくれません。資源を提供するだけで、いつ、どこで、何を必要とするかはあなた次第なのです。
 
Amir Yacoby:
OK、わかったような気がします。手続き型からOOP型になると、コンセプトがずれるという問題が本当にありますね。
つまり、CTradeの存在を知らなくても、CTrendLineのプライスクロスをイベントによってCTrade継承オブジェクトに通知する方法ということでよろしいでしょうか？
私はそう主張します。
 
そのため、実際には各CObjectは イベントの受信者である1つのオブジェクトの場所を持ち、また、そのように購読するリスニングオブジェクトのための登録メソッド、イベント送信者メソッドと受信者が使用するイベントハンドラメソッドを持っています。

これはいいですね、observerパターンを思い出します。ただ、observerは複数の受け取り手があり、m_recieverはオブジェクトの配列になっています。

実は、私もオブザーバーを実装したかったのですが、MQLにはインターフェースがなく、また多重継承ができないため、実装しませんでした。同じオブジェクトが双方でインターフェイスを強制することができるという、あなたの良いアイデアについては考えもしませんでした。


 
Amir Yacoby:
そのため、実際に各CObjectはイベントの受信者である1つのオブジェクトの場所を持ち、また、そのように購読するためのリスニングオブジェクトの登録メソッド、イベント送信者メソッド、受信者が使用するイベントハンドラメソッドを持っています。

これはいいですね、observerパターンを思い出します。ただ、observerは複数の受け取り手があり、m_recieverはオブジェクトの配列になっています。

実は、私もオブザーバーを実装したかったのですが、MQLにはインターフェースがなく、また多重継承ができないため、実装しませんでした。同じオブジェクトが双方でインターフェイスを強制することができるという、あなたの良いアイデアについては考えもしませんでした。


ただ、励みになるのは、私はMQL4でリスナーを多用していることです。
 
Ovo Cz:
ただ、励みになるのは、私はMQL4でリスナーをよく使うようになったことです。

ありがとうございます、でも励まされた気がしません（。

つまり、パブリッシャーはリスナーがハンドリングメソッドを持っていると仮定しなければならないのですが、何も持っていることを強制されることはありません。
リスナーは他のクラスを継承することができないので、もちろん意味がありません。

とにかく、私はプログラミングのプロですが、今のところ経験が不足しているOOではありませんし、Doerkのような経験豊富なOOプログラマーの皆さんと競争しているわけでもないのです。
私のような手続き型の人間が、OOフレームワークを作るというミッションに直面すると、全く異なる精神状態になるのです。また、GUI部分のフレームワークは、多くのイベントを扱う最も細かいフレームワークで、フレームワークの中で最も作るのが難しいというのは、皆さんも同意していただけると思います。

12345
新しいコメント