構造のルール プログラムの構成方法を学び、可能性、エラー、解決策などを探る。 - ページ 7 1234567891011121314...20 新しいコメント Vladimir Gomonov 2013.07.23 00:40 #61 Urain:基本的なデザインパターンを並べることをお勧めします。1.機能的2. オブジェクトモデル3.イベントドリブン....タイプイン4.コンポーネント--一般に、どんなプログラムも（あなたの意図するものも含めて）、さまざまな角度から見ることができます。// それは理解できる。私は、プロジェクトの初期分析において、少なくとも4つの側面を考慮するようにしています。1.構造的：プログラムコードおよびプログラムコンポーネントの物理的および論理的な構成。2.機能的（開発における機能的アプローチと混同しないように）：プログラムがどんなタスクを解決するか（どんな製品を生み出すか）、その用途は何か、どんな出力を出すべきか、など。3.コミュニカティブ：プログラムが持つべきユーザーインターフェイスの種類、どのプログラムとどのように通信 するか、通信プロトコルなど。4.管理面：ソフトウェアの管理方法、必要な設定、自由度など。すべての側面は表裏一体ですが、これらの異なる角度（＋α）から見ることで、重要な機微を見逃すことなく、また、初期の段階では、重大な結果をもたらす重要なものをあくびせずに済むのです......」。) Denis Kirichenko 2013.07.23 08:08 #62 MetaDriver:...一般的に、どんな番組も（構想も含めて）さまざまな角度から見ることができます。// これは理解できる...。全く同感です。これは哲学の一般的な原則で、ある現象をさまざまな視点から研究すること...。そして、開発の初期に「プログラムは何をすべきで、何をすべきでないか」という問いに答えようとしているのです。質問の最初の部分はシステム（ここではMTS）の中にあり、2番目の部分はそうではなく、外にあります。デザイン モデルに関わらず、モデル要素の階層を持つことは非常に重要だと思います。そして、「一般から特定へ」という演繹的手法がうまく機能し、モデルを主要な構成要素に分解することができるのです。 Vasiliy Sokolov 2013.07.23 08:47 #63 MetaDriver:意見交換／学び合いのために、多かれ少なかれ現実的な問題を取り上げ、それをみんなで再構築することを提案します。例えば、そのような問題に対する基本構造（より正確には、そのような構造のバリエーション）の概要くらいは教えてください。このようなExpert Advisor（取引アイデアのテスト用）があります。 Strategy Tester（クライアント側）のアイデアが有望な結果を示したとします。 ここで、Expert Advisorをより開発しやすいように書き換える必要があります。特に、グラフィカルなユーザーコントロールパネルを提供 する必要があります。テスターで最適化するために）パネルを切り替えられるようにするか、EAの「非グラフィカル」な実現をプラグイン可能なファイル（.mqh）に移動し、「テスター」バージョンと「グラフィカル」バージョンの操作の違いを（排除するために）変更せずに グラフィカルインターフェースに接続することが望まれます。このようなプロジェクトの構成、特にイベントドリブン制御モデルの実装について、考察をお聞かせください。二重実装（テスター＋パネル）が顧客の厳しい要求であるとする（つまり、プロジェクトはどのような方法でも行わなければならず、あなたは実装方法のみを選択することができる）。試しにやってみましょうか。Expert AdvisorのコントロールパネルとExpert Advisorは、1つのプログラムの中にある全く別のモジュールであることは明らかだと思います。そのため、それぞれのパーツが独立するように分離する必要があります。つまり、Expert Advisor の一部を変更（例えば、注文を出すロジックを変更）しても、パネルのロジックを変更する必要はなく、逆にパネルのインターフェースを変更しても、Expert Advisor のロジックを変更する必要はない、ということです。まず思いつくのは、パネルとExpert Advisorが通信 するための統一されたインターフェースの作成です。しかし、残念ながらMQL5の制作者は水平リンクを作成する可能性を考慮していないため、MQL5によってそれらの間のインターフェイスを記述してもうまくいかないのです。そうすると、垂直統合の道が残る。Expert Advisorはベースクラスを継承する必要があり、ベースクラスにはパネルとの対話に必要なメソッドとデータが含まれています。つまり、ベースクラスから継承したEAも、パネルの表示や操作ができるようになります。パネルとのインタラクションを担うメソッドの実装は、子孫に委ねず、ベースクラスの裏で行わなければなりません。パネルと対話するには、このようなメソッドをこのようなパラメータで呼び出す必要があります」というのは、まったく機能しません。理想的には、ベースクラスを継承する派生Expert Advisorは、単に便利な方法で取引を行い、そのアクションが自動的にこのパネルに表示されるようにすることです。普遍的なベースクラスをどう編成するかは、別に興味深いテーマです。この件に関しては、数年にわたる実践を経て、ようやく私の普遍的なスキームにたどり着きました。透明で普遍的なものであることがわかりました。もし興味があれば、その基本的なフローチャートを提供することができます（ハハハ、フローチャートを描くことは結局とても役に立つ活動なのです）。しかし、いずれにせよ、人には人のやり方があり、ある人にとっての良い解決策が、他の人にとっての良い解決策とはならない。 --- 2013.07.23 09:42 #64 C-4:もし興味があれば、回路図を差し上げます（あはは、ブロック図を描くのは結局役に立つ活動なのです）。 Vladimir Gomonov 2013.07.23 10:16 #65 sergeev: やっと何かがクリアになったような...。) Vladimir Gomonov 2013.07.23 10:32 #66 C-4:まず思いつくのは、パネルとEAがデータをやり取りするための統一されたインターフェースの構築です。 残念ながら、MQL5の制作者は水平リンクを作成する可能性を提供しなかったため、MQL5のツールを使用してそれらの間のインターフェイスを記述することは不可能です。 1.曖昧にしない。2.カスタムイベントについてはどうでしょうか。 かなり横並びで普遍的なものだと思います。3.そうなると、垂直統合の方法が残る。Expert Advisorはベースクラスを継承する必要があり、ベースクラスにはパネルと対話するのに十分なメソッドとデータが含まれています。これは、ベースクラスから継承されたExpert Advisorもパネルを表示し、対話する能力を得ることを意味します。パネルとのインタラクションを担うメソッドの実装は、子孫に委ねず、ベースクラスの裏で行わなければなりません。パネルと対話するには、このようなメソッドをこのようなパラメータで呼び出す必要があります」というのは、まったく機能しません。理想的には、ベースクラスから継承された派生Expert Advisorは、単に便利な方法で取引を行い、そのアクションは自動的にそのパネルに表示されることである。2に同意できないので、このバリエーションはまだ掘っていません。--私は、非常に魅力的な代替案を持っています（「切断可能な」パネルを持つバリアント）。 インジケータの形でパネルを作成します。 Expert Advisor が Strategy Tester にある場合、パネルを読み込まないようにするだけです。さらに、パネルが別のスレッドで実行されるため、Expert Advisor に多くのリソースを割り当てることができます。パネルの汎用性については、iniファイルによるフルコンフィグが可能であることに大きな支障はないと思います。つまり、限られたビジュアルコンポーネントと、ユーザーとのインタラクション時に生成すべきイベントコードから、任意のパネルを作成するために必要なデータのすべてを、そこに絶対的に規定することができるのです。普遍的なベーストレーディングクラスをどのようにアレンジするかは、別途興味深いテーマです。このテーマについて数年間実践し、ついに私の普遍的なスキームにたどり着いたのです。それは、透明で普遍的なものであることがわかりました。もしご興味があれば、基本的なブロック図をお見せすることができます。.... 私はとても興味がありますし、実用的です。 TheXpert 2013.07.23 10:36 #67 MetaDriver:1.曖昧にしない。Nahr なぜ？過剰なユニバーサル化は、早すぎる最適化と同じくらい邪悪なものです。また、イベントによる1つのモジュールのブロックの結合は......。...は遅くて不便です。 Vasiliy Sokolov 2013.07.23 12:10 #68 MetaDriver:さあ、実はかなり興味がありますし、実際に役に立つかもしれません。青い枠がベースクラスの実体です。赤枠は派生クラスの実体です。ベースクラスがそのロジックの定義を4つのメソッドでディセンダントに課していることがわかる。これは、どんな戦略の記述も、たった4つの状況の記述に還元してしまうというものです。1.ロングポジションを開くためのすべてのルールが遵守されている場合、InitBuy()メソッドでロングポジションが開かれます。2.ロングポジションの決済のためのすべてのルールが満たされている場合 - ロングポジションはSupportBuy()メソッドを使用して決済されます。 3.ショートポジションを開くためのすべてのルールが満たされている場合、InitSell()メソッドを使用してショートポジションが開かれます。4.ショートポジションを閉じるためのすべてのルールが満たされている場合、SupportSell()メソッドでショートポジションが閉じられます。このロジックによれば、ストラテジーリバーサルは1つの手法（例えばクローズロングオープンショート）ではなく、互いに依存しない2つの手法で記述されることになります。この方法は、例えば、ベースクラスで記述できる一般的な条件を満たした後、ワンクリックで売りを禁止したり、ポジションを強制的に閉じることができるので、非常に便利であることがわかります。場合によっては、販売と購入の両方の一般的なデータがあり、新しいバーの到着など、何らかのイベントの発生時に再計算される必要があります。このような場合、ストラテジーは独自の処理方法をイベントにサブスクライブすることが可能である。これらの方法では、ポジションを建てることはできませんが、様々な計算をすることは可能です。 もうひとつ興味深いのは、オープンポジションをどう扱うかという点です。基本クラスは、ロングポジションとショートポジションの個別のリストを格納します。新しいイベントが発生すると（例えばOnTick）、クラスはすべてのオープンポジションのリストを開始し、SupportBuy SupportSellメソッドを使用してこれらのポジションを1つずつ処理することを提案します。これらのメソッドは、ベースクラスから現時点で提供されているポジションのみを閉じることができます。それ以外のポジションは読み取り専用です。このように、ベースクラスはその子孫に対して、現時点では1つのポジションにのみフォーカスしなければならないという考えを課している。このアイデアを検証してみると、どんなに複雑なExpert Advisorでも、ロジックはもっとシンプルであることがわかりました。さらに、Expert Advisorがロングとショートのポジションに関する情報を保持しているため、ヘッジの概念を自動的にサポートします。 GaryKa 2013.07.23 12:31 #69 TheXpert: ...トレーディング部分の実装はストラテジーに依存するので、仮定のストラテジーの枠内で議論することはない。不思議なことに戦略の実行は、戦略にも左右されるのです :)MetaDriver: ...取引部分全体はクラス（CMarketDriver）の形で書かれており、注文の発注、ポジションの追跡、リクオート、その他の取引に関連するものを完全に実装しています。すべてのシンボルを一度にストラテジー部は、シンボルの推奨ポジションを受け取るだけです。つまり、{string Instrument; double Position}形式の構造体の配列を埋めて、サーバーに同期を要求します。 MD.Synchronize(PositionArray) 以上です。現在は成行注文のみですが、スプレッド内に指値を設定して取引するバージョン（取引コストを削減するため）も準備中です。取引ではテイクプロフィット/ストップは使用しませんが、MarketDriverはサーバーへの接続が長時間失われた場合に備えて保護ストップを置くことができます（ストップパラメータはドライバー設定で一度指定します）。 ところで、非常に成功した、ほとんど問題のない構造ソリューションです。 テスターで戦略的アイデアをテストするには、取引で問題がない、すべての注意を戦略に注ぐことができます - すべての取引が長いデバッグと取引ドライバーにカプセル化されています。ストラテジーの実行を指値注文に変換し始めると、なぜか質問が多くなる。ストラテジー部分（アナライザー/プログノベーター/ブレーン）にヒットする価格に対するリミッターの効果。マルチカレンシー戦略のための同期化トレンドトレードで約定しないことが続く（トロール？ もしそうなら、どのように、または、スピットしてマーケットに従う。）一部実行...そして、「実行者」と「解析者」の間のフィードバックを実装し、さらに、この非理想的な動きのパラメータを解析者の数学的モデルに何らかの形で組み込む必要があるのですMetaDriver: ...テスターで戦略的なアイデアを確認するには、歌 - 取引に問題はありません... そう、リミッターにとっては、まさに「歌」なのです。 TheXpert 2013.07.23 13:11 #70 GaryKa:ストラテジーでの執行を徹底的に指値注文に変えていくようになると これはあくまで一例ですが、トレーディングの部分は戦略次第です。 1234567891011121314...20 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
基本的なデザインパターンを並べることをお勧めします。
1.機能的
2. オブジェクトモデル
3.イベントドリブン.
...
タイプイン
4.コンポーネント
--
一般に、どんなプログラムも（あなたの意図するものも含めて）、さまざまな角度から見ることができます。// それは理解できる。
私は、プロジェクトの初期分析において、少なくとも4つの側面を考慮するようにしています。
1.構造的：プログラムコードおよびプログラムコンポーネントの物理的および論理的な構成。
2.機能的（開発における機能的アプローチと混同しないように）：プログラムがどんなタスクを解決するか（どんな製品を生み出すか）、その用途は何か、どんな出力を出すべきか、など。
3.コミュニカティブ：プログラムが持つべきユーザーインターフェイスの種類、どのプログラムとどのように通信 するか、通信プロトコルなど。
4.管理面：ソフトウェアの管理方法、必要な設定、自由度など。
すべての側面は表裏一体ですが、これらの異なる角度（＋α）から見ることで、重要な機微を見逃すことなく、また、初期の段階では、重大な結果をもたらす重要なものをあくびせずに済むのです......」。)
...一般的に、どんな番組も（構想も含めて）さまざまな角度から見ることができます。// これは理解できる...。
全く同感です。これは哲学の一般的な原則で、ある現象をさまざまな視点から研究すること...。
そして、開発の初期に「プログラムは何をすべきで、何をすべきでないか」という問いに答えようとしているのです。質問の最初の部分はシステム（ここではMTS）の中にあり、2番目の部分はそうではなく、外にあります。
デザイン モデルに関わらず、モデル要素の階層を持つことは非常に重要だと思います。そして、「一般から特定へ」という演繹的手法がうまく機能し、モデルを主要な構成要素に分解することができるのです。
意見交換／学び合いのために、多かれ少なかれ現実的な問題を取り上げ、それをみんなで再構築することを提案します。
例えば、そのような問題に対する基本構造（より正確には、そのような構造のバリエーション）の概要くらいは教えてください。
このようなExpert Advisor（取引アイデアのテスト用）があります。 Strategy Tester（クライアント側）のアイデアが有望な結果を示したとします。 ここで、Expert Advisorをより開発しやすいように書き換える必要があります。特に、グラフィカルなユーザーコントロールパネルを提供 する必要があります。
テスターで最適化するために）パネルを切り替えられるようにするか、EAの「非グラフィカル」な実現をプラグイン可能なファイル（.mqh）に移動し、「テスター」バージョンと「グラフィカル」バージョンの操作の違いを（排除するために）変更せずに グラフィカルインターフェースに接続することが望まれます。
このようなプロジェクトの構成、特にイベントドリブン制御モデルの実装について、考察をお聞かせください。二重実装（テスター＋パネル）が顧客の厳しい要求であるとする（つまり、プロジェクトはどのような方法でも行わなければならず、あなたは実装方法のみを選択することができる）。
試しにやってみましょうか。
Expert AdvisorのコントロールパネルとExpert Advisorは、1つのプログラムの中にある全く別のモジュールであることは明らかだと思います。そのため、それぞれのパーツが独立するように分離する必要があります。つまり、Expert Advisor の一部を変更（例えば、注文を出すロジックを変更）しても、パネルのロジックを変更する必要はなく、逆にパネルのインターフェースを変更しても、Expert Advisor のロジックを変更する必要はない、ということです。まず思いつくのは、パネルとExpert Advisorが通信 するための統一されたインターフェースの作成です。しかし、残念ながらMQL5の制作者は水平リンクを作成する可能性を考慮していないため、MQL5によってそれらの間のインターフェイスを記述してもうまくいかないのです。そうすると、垂直統合の道が残る。Expert Advisorはベースクラスを継承する必要があり、ベースクラスにはパネルとの対話に必要なメソッドとデータが含まれています。つまり、ベースクラスから継承したEAも、パネルの表示や操作ができるようになります。パネルとのインタラクションを担うメソッドの実装は、子孫に委ねず、ベースクラスの裏で行わなければなりません。パネルと対話するには、このようなメソッドをこのようなパラメータで呼び出す必要があります」というのは、まったく機能しません。理想的には、ベースクラスを継承する派生Expert Advisorは、単に便利な方法で取引を行い、そのアクションが自動的にこのパネルに表示されるようにすることです。
普遍的なベースクラスをどう編成するかは、別に興味深いテーマです。この件に関しては、数年にわたる実践を経て、ようやく私の普遍的なスキームにたどり着きました。透明で普遍的なものであることがわかりました。もし興味があれば、その基本的なフローチャートを提供することができます（ハハハ、フローチャートを描くことは結局とても役に立つ活動なのです）。しかし、いずれにせよ、人には人のやり方があり、ある人にとっての良い解決策が、他の人にとっての良い解決策とはならない。
もし興味があれば、回路図を差し上げます（あはは、ブロック図を描くのは結局役に立つ活動なのです）。
まず思いつくのは、パネルとEAがデータをやり取りするための統一されたインターフェースの構築です。
残念ながら、MQL5の制作者は水平リンクを作成する可能性を提供しなかったため、MQL5のツールを使用してそれらの間のインターフェイスを記述することは不可能です。
1.曖昧にしない。
2.カスタムイベントについてはどうでしょうか。 かなり横並びで普遍的なものだと思います。
3.そうなると、垂直統合の方法が残る。Expert Advisorはベースクラスを継承する必要があり、ベースクラスにはパネルと対話するのに十分なメソッドとデータが含まれています。これは、ベースクラスから継承されたExpert Advisorもパネルを表示し、対話する能力を得ることを意味します。パネルとのインタラクションを担うメソッドの実装は、子孫に委ねず、ベースクラスの裏で行わなければなりません。パネルと対話するには、このようなメソッドをこのようなパラメータで呼び出す必要があります」というのは、まったく機能しません。理想的には、ベースクラスから継承された派生Expert Advisorは、単に便利な方法で取引を行い、そのアクションは自動的にそのパネルに表示されることである。
2に同意できないので、このバリエーションはまだ掘っていません。
--
私は、非常に魅力的な代替案を持っています（「切断可能な」パネルを持つバリアント）。 インジケータの形でパネルを作成します。 Expert Advisor が Strategy Tester にある場合、パネルを読み込まないようにするだけです。さらに、パネルが別のスレッドで実行されるため、Expert Advisor に多くのリソースを割り当てることができます。
パネルの汎用性については、iniファイルによるフルコンフィグが可能であることに大きな支障はないと思います。つまり、限られたビジュアルコンポーネントと、ユーザーとのインタラクション時に生成すべきイベントコードから、任意のパネルを作成するために必要なデータのすべてを、そこに絶対的に規定することができるのです。
普遍的なベーストレーディングクラスをどのようにアレンジするかは、別途興味深いテーマです。このテーマについて数年間実践し、ついに私の普遍的なスキームにたどり着いたのです。それは、透明で普遍的なものであることがわかりました。もしご興味があれば、基本的なブロック図をお見せすることができます。....
1.曖昧にしない。
Nahr なぜ？過剰なユニバーサル化は、早すぎる最適化と同じくらい邪悪なものです。
また、イベントによる1つのモジュールのブロックの結合は......。...は遅くて不便です。
さあ、実はかなり興味がありますし、実際に役に立つかもしれません。
青い枠がベースクラスの実体です。赤枠は派生クラスの実体です。ベースクラスがそのロジックの定義を4つのメソッドでディセンダントに課していることがわかる。これは、どんな戦略の記述も、たった4つの状況の記述に還元してしまうというものです。
1.ロングポジションを開くためのすべてのルールが遵守されている場合、InitBuy()メソッドでロングポジションが開かれます。
2.ロングポジションの決済のためのすべてのルールが満たされている場合 - ロングポジションはSupportBuy()メソッドを使用して決済されます。
3.ショートポジションを開くためのすべてのルールが満たされている場合、InitSell()メソッドを使用してショートポジションが開かれます。
4.ショートポジションを閉じるためのすべてのルールが満たされている場合、SupportSell()メソッドでショートポジションが閉じられます。
このロジックによれば、ストラテジーリバーサルは1つの手法（例えばクローズロングオープンショート）ではなく、互いに依存しない2つの手法で記述されることになります。この方法は、例えば、ベースクラスで記述できる一般的な条件を満たした後、ワンクリックで売りを禁止したり、ポジションを強制的に閉じることができるので、非常に便利であることがわかります。
場合によっては、販売と購入の両方の一般的なデータがあり、新しいバーの到着など、何らかのイベントの発生時に再計算される必要があります。このような場合、ストラテジーは独自の処理方法をイベントにサブスクライブすることが可能である。これらの方法では、ポジションを建てることはできませんが、様々な計算をすることは可能です。
もうひとつ興味深いのは、オープンポジションをどう扱うかという点です。基本クラスは、ロングポジションとショートポジションの個別のリストを格納します。新しいイベントが発生すると（例えばOnTick）、クラスはすべてのオープンポジションのリストを開始し、SupportBuy SupportSellメソッドを使用してこれらのポジションを1つずつ処理することを提案します。これらのメソッドは、ベースクラスから現時点で提供されているポジションのみを閉じることができます。それ以外のポジションは読み取り専用です。このように、ベースクラスはその子孫に対して、現時点では1つのポジションにのみフォーカスしなければならないという考えを課している。このアイデアを検証してみると、どんなに複雑なExpert Advisorでも、ロジックはもっとシンプルであることがわかりました。さらに、Expert Advisorがロングとショートのポジションに関する情報を保持しているため、ヘッジの概念を自動的にサポートします。ストラテジーの実行を指値注文に変換し始めると、なぜか質問が多くなる。
そして、「実行者」と「解析者」の間のフィードバックを実装し、さらに、この非理想的な動きのパラメータを解析者の数学的モデルに何らかの形で組み込む必要があるのです
MetaDriver: ...テスターで戦略的なアイデアを確認するには、歌 - 取引に問題はありません...
ストラテジーでの執行を徹底的に指値注文に変えていくようになると