無効なリクエスト - 始めたばかりで理解できない... - ページ 6

新しいコメント
 
-Alexey-:

なぜかというと、私は自分のために1つ書いたことがありますが、4つのために書いたのです。

つまり、EAのビジネスロジックから切り離され、どのEAでも使えるユニバーサルなライブラリを作成されたのですね。

私も信じていません。もちろん、サーバーレスポンスハンドラーのコードはありましたが、すべてビジネスロジックの中にあり、ユニバーサルライブラリとしてではありません。

 
Renat:

EAのビジネスロジックから切り離され、どのEAでも使えるユニバーサルなライブラリを個人的に書かれたわけですね。

私も信じていません。もちろん、サーバーレスポンスハンドラーのコードはありましたが、すべてビジネスロジックの中にあり、ユニバーサルライブラリとしてではありません。

はい、証明できます。もちろん、ある程度の金額であれば。
 
-Alexey-:
はい、証明できます。もちろん、対価を払って。

というか、MT4用のライブラリもないんですよね。

証明するのはそれほど難しいことではなかったのです。

 
Renat:

つまり、MT4用のライブラリも存在しないのです。

証明するのはそれほど難しいことではなかったのです。

つまり、存在するのです。振込後、今すぐ提供されます。でも、4にも5にもないんですね。
 
Renat:

レナト標準ライブラリの使用は、「OOPか、OOPでないか」の大合唱に該当するような気がしています。

そうでなければ、取引操作を簡略化するOOPラッパーを使うべきでないという強い信念を持つ人がいることが理解できないのです。

すべてのロジックを実行し、エラーを処理し、クエリーを繰り返すラッパーを主張する人もいます。そして同時に、その使用は危険であるとされており、すべての行に誤りがある...。

 
-Alexey-:
つまり、あるのです。

すべてのエラーはビジネスロジックで処理されます。
MT4のシンクロニシティ・プロパティを利用することで、ある程度処理を簡略化することができますが、あなたの方法ではすべてのケースを100%保証することはできません。おそらく95%は、取引プロセス全体がベースとなる、純粋にあなたのバイブルとなるものです。
しかし、MT5はリターンコードの処理＋非同期という点で何倍も複雑なのです。

ラッパーに不可能を求めるのか。標準ライブラリはビジネスロジックではありません。端末の機能を「覆う」ラッパーなのです。お菓子の詰め物の上にかぶせる包み紙のこと。
ルーティンの一部を引き継ぐ、使いやすいインターフェイスです。同じようなコードを引き継ぐこと。紙の包み紙を食べて、なぜ食べられないのかと文句を言うことはない。:)

しかし、ラッパーは保証人になっているのだから、何も保証できない。あなたのビジネスロジック:)
印刷機能がディスクの空き容量やログのエラーを保証できないのと同じです。エラー処理には他の関数を使用する必要があり、それらはケースバイケースです。


-Alexey-、 具体的な欠点についてチャットしましょう、あなたは修正したい具体的な 欠点を声に出しています。

必要であれば、それぞれのリターンコードを調べて、考えられる主な状況を確認することができます。

 
papaklass:


質問に答えてください。
- なぜ、61ものメソッドを引きずったままなのか？合理的か？

問題は、OOPプログラミングが必要なのかどうかという面に行き着きます。一義的に答えることはできません。
私の実務では、高水準のモデルにはOOPを使います。
もちろん、私のベースでも機能だけでたくさん使っています。

それは、まるでkanvasの描画ライブラリのような機能です。線と四角と文字がある。しかし、このクラスが四角を持つべきかどうかということは、何も議論する必要はない。ただ、そこにあるのです。特定のタスクのために


一つの授業の中で解決しようとしている問題が多すぎるのです。

あなたは間違っています。RUTINAに 巻きついているのです。


そのため、エラー処理は解決すべきすべてのタスクに対して行う必要があります。

ありえない。聖書は何の問題も解決してくれないので。それ以上のことはできないし、複雑である必要もないのです。

解決策は簡単で、面倒なクラスを、解決すべき問題に応じて、いくつかの小さなクラスに分割すればよいのです。
この場合、私は自分の戦略に合うクラスだけを巻き込み、余計なものは一切巻き込まないようにします。また、エラー処理の実装も今よりずっと簡単にできるようになるはずです。

まあ、包み込むようなルーティンではないんですけどね。それはもう、あなたの 専門家特有のロジックで問題を解決してくれる。
意図したエラー処理がうまくいかず、別の処理をしなければならないケースは、常に1001件あります。

あらゆる状況に対応できる普遍的な関数をご存知の方は、ぜひ教えてください。EAのロジックを知らないのに、起こりうるすべてのエラー処理を事前に用意することが可能なのか、想像もつきません。
仮に私がそのような機能を作ったとしても、 「また騒ぎ 立てたのか」というあなたの上から目線の言葉とは矛盾してしまいます。

また、方向性を持ったマクロによるコードの書き方（ORDER_TYPE_BUY / ORDER_TYPE_SELL）を適用すれば、クラスはかなりコンパクトになりますね。
どこにあるんだろう？

しかし、マクロにもエラー処理はなく 、特定のExpert Advisorのビジネスロジックで、特定のエラーで処理されます。普遍的なシチュエーションがないことは、それほど難しいことではありません。

もしRenatがフォーラムからの提案に耳を傾け、その意味を理解しようと学ぶなら、MT5はすでに今の開発段階よりずっと先に進んでいたでしょう。

レナートは何度も言いますが、ここは技術フォーラムなのです。 ここでは抽象的な話はできないのです。

では、具体的に教えてください。条件、彼が必要とする取引機能、起こりうるエラーとその対処法について考えてみよう。

 
papaklass:

質問に答えてください。

- 成行注文や未決済注文を出すだけなら、なぜ61ものメソッドを引きずる必要があるのでしょうか？合理的か？

- もし私がオープンポジションを持っていて、ストップを設定する必要があるだけなら、なぜ61のメソッドでその機能をすべて引きずる必要があるのでしょうか？合理的か？

- もし私がオープンポジションを持っていて、価格がそのレベルに達したときにトリガーされるストップがある場合、なぜこれら61のメソッドをすべてドラッグする必要があるのでしょうか？合理的か？

誰もあなたを禁じてはいません。

  1. 誰かが書いたライブラリなどの既製品を使うのではなく、自分で一からコードを書く。
  2. 既に用意されているライブラリを、あなたの意見で「不要」と思われるメソッドを削除して、修正したクラスの形で書き直す。
  3. を継承して、既成のライブラリのメソッドをオーバーライドする。
 
papaklass:

トレードの ための操作を別のクラスに分ける」ことに何の意味があるのか。

オープン、クローズ、モディファイで別々のEAを用意したのと同じです。できそうで、誰もやらない（稀な例外、特殊な作業を除いて）。

そして、「成行注文や未決済注文を出すだけなら、61種類ものメソッドをすべて引き ずっていく必要はない」という言葉がとても気に入っています。合理的か？"

Expert Advisor 1つにつき、約100kbのメモリのオーバーヘッドが発生します。げっ...


ちなみに、こんな投票もあります。 トレーディングの操作に標準 ライブラリを使いますか？

 
papaklass:

正直なところ、私の投稿は出てくるべきものではありませんでした。

何もないわけではない、型破りなのは自分だけではないと気づいた :) 投票で - お礼参りしました。
12345678
新しいコメント