Представьте на минутку обычного программиста. Допустим, его зовут Вася и ему нужно сделать анимированную менюшку на сайт/десктоп приложение/мобильный апп. Знаете, которые выезжают сверху вниз, как меню у окна Windows или меню с яблочком у OS X. Вот такое. Начинает он с одного выпадающего окошка, тестирует анимацию, выставляет ease out 100% и...
私が賢いと思わないで、この 戦闘用TCを書くというアーキテクチャを もう一度見てみてください。フィードバックがない。
仮想のポジションがあり、仮想にフィットした現実の取引環境がある。
その場合、ネッティングがプラットフォームか他の会計システムであるかも関係ない。
特に通常のテスターでは確認できない高速ストラテジーの場合、非常に面白い仕組みだと思います。
ただ、「スマートシンクロナイザー」については、よくわからないのです。おそらく彼らは、私が正しく理解していれば、そのタスクは、仮想収益性/戦略の収益性と市場の現在の状態 - 流動性、実行速度などを調整することです取引注文の適応型コピー機を意味します...。
一般的には、このようなテスターやシンクロナイザーをExpert Advisorにモノリシックに組み込むのではなく、別の外部モジュールとして用意することが望ましいとされています。
この場合、任意のExpert Advisorまたは複数のExpert Advisorを接続し、最適な信号を選択的に使用することも可能です。
MQLだけで現実的なのだろうか...。
これは、ロジック的には別モジュールです。
例えば、Signalsサービスは 別モジュールで、TSとは一切関係がない。
これは、仮想のソースポジション（それらはあなたにとって仮想である）を、あなたの取引環境に変換するだけです。
もちろん、不思議なことに（最適ではない）、翻訳されるのです。
これは、ロジック的には別モジュールです。
例えば、Signalsサービスは 別モジュールで、TSとは一切関係がない。
これは、仮想のソースポジション（それらはあなたにとって仮想である）を、あなたの取引環境に変換するだけです。
もちろん、不思議なことに（最適ではない）、翻訳されるのです。
それは曲がった翻訳をするGoogleの翻訳者があることが判明したが、あなたがそれを理解する必要がない場合は行いますが、あなたはそれを正確に理解する必要がある場合 - 言語を学ぶ）。
翻訳がうまくいって、EAごとにコードを書く必要がない場合は、中間的な選択肢、つまり個人的な高品質の翻訳者（モジュール）でも満足です。
プログラムの構成は、経験を積むことで分かってきます。ここにいる皆さんはそれぞれ違う経験をしているので、構造化の順番やルールもそれぞれでしょう。さらに、これらのルールは時代とともに変化します。つまり、数年前には理想的と思われた構造が、今日では軽い批判にも耐えられないかもしれないのです。
MQLは本質的にDSLであり、端末からのイベントによって制御されるため、プログラムの構造は別の曲となります（ただし、汎用言語に近づけるために大きなステップが踏まれています）。トレーディング戦略を記述するのに最適な方法は、ステートマシンだと思います。実際、この構造は、各ケースを実現するために多くのencludeを持つ大きなケースに縮退しています。
私は通常、取引業務を抽象化し、ユーザーとのインタラクションの詳細については何も知らないコア部分を割り当てます。その目的は、自分自身にデータを入れ、受け取ったデータに基づいて問題を解き、その結果を出力する方法を提供することである。コアは物理的には複数のファイルから構成されるかもしれないが、そのすべてが論理的に接続され、データを受け取るメソッドとデータを返すメソッドのみを外部に提供し、それ以外のものは提供してはならない。最も簡単な例えは、肉挽き器です。
もう一つは、変更する部分（あるいは変更する可能性のある部分）をローカライズして、別の抽象的なものに分離することが重要だと考えています。この手法では、異なる機構の実装をシームレスに切り替えることができます（例えば、ポジションオープンの 機構を切り替えることで、取引の仮想化を実現します）。異なる実装は、一般的な名前で別のフォルダーに保存されるのが便利です。
プロジェクトの構造は、異なるサブシステム（Subsystems）からなる幹（Core）と、そこから分岐する変更可能な動作（Behaviour）の枝を持つ木のようなものになる。そしてその横には、この木を必要な角度から見るための双眼鏡（Reporting, GUI）と、この木に必要なインタラクションを提供する斧とチェーンソー（Actions, GUI）が用意される予定です。
開発者のためのシンプルなステートマシン
開発者のためのシンプルなステートマシン
少なくとも、私たちの現実に適用できるようなおおよその例を挙げてください。
あなたは本当にすごい人だ :) どんな戦略の実装も、基本的にはステートマシンです。
わかりました。 チャラブラの記事を踏まえて、そのような機械の例を教えてくださいとお願いしました。
そういやステートマシンの「アナログ」を作ったって記事があったな。そして、この技術を最先端のプログラミング・イノベーションとして押し出していたのである（笑)。
しかし、ここではステートマシンに関する実質的な記事は思い出せません。ここでは記憶にない。
少なくとも、私たちの現実に適用した大まかな例を挙げてください。
嗚呼、「何が証拠になるか」を思い出しますね。
ステートマシン」でググって、一番気に入った内容をピックアップしてここにアップしただけです。
何も証明しないし、何も反証しない。興味深い記事です。
私は基本的にドグマには反対で、ある人が使っていても、他の人に合うとは限りません。
しかし、他の人のコードを読んでいると、ステートマシンのアナロジーに出会うことがよくあります。単なる観察です。