構造のルール プログラムの構成方法を学び、可能性、エラー、解決策などを探る。 - ページ 10

新しいコメント
 

Stateのプログラミングは、私自身も数年前から使っていて、知らない人はいないでしょう。しかし、この方法をしばらく使った後、私はこの方法をやめ、より透明でシンプルな、より適切な取引モデルを開発することにしました。

この記事を読む:自動売買システムを作るための新しい方法としての自動プログラミング

そして、それに対するこれらのコメントを よく読んでください。

そして、その記事の中にある見苦しい額の一つを、とてもとても丁寧に考え、それが何を意味するのか考えてみてください。

ここまで読んで、まだ "すごい！ステート・プログラミングってかっこいい！"と思われた方。- まあ、期待してください。

ステート・プログラミングの主な問題は、無駄なモード（コラムNステート参照）が多く発生する状況であることを付け加えておく。ステートプログラムでは、各モードで個別にルールを記述する必要があります。例で説明しましょう。例えば、「買う」モードだとします。ロボットがもう1つポジションを開けることを決めるまでは、すべてが順調だった。そして、なぜいけないのか？古いポジションから出る条件が満たされておらず、決済するには早すぎる。一方、新しいシグナルは見逃してはならない。そして、ここからが問題なのですが、新しいシグナルが到着した瞬間にロボットは買いモードになり、新しいポジションを開くためのルールは状態モード（新しいエントリーシグナルを待ち、探す）になるからです。さて、「買い」モードでは、「状態」モードで使用するのと同じポジション・オープン・ルールを再度記述する必要があります。また、新しいポジションが逆の方向（ヘッジ）であった場合は？このポジションはオープンだが、どうすればいいのか？結局、その管理ロジックは、ロボットが買いモードであるのに対して、売りモードで記述されています。売りに切り替えればいいだけですが、残った買いポジションはどうすればいいのでしょうか？一般に、この場合、BuyAndSellのような無駄なモードをもう一つ書かなければならない。モードの冗長性により、もう一つ別の状況が生まれます。1つの同じ動作が異なるコードセクションで実行されるのです。全体として、指数関数的なプログラミングの混乱が好きな人にとって、これは最良の解決策だと思います。

 
C-4:
(fcplm)
 
C-4:

"それがミハイル"(C)・・・。私もそれを暗示しているんです。

TheXpert です。
(fcplm)

まさかね。

 
C-4:
MQL5が多重継承をサポートし、クラスが抽象的なメソッドを宣言できるようになれば、インターフェースを使う道が開け、大規模なプロジェクトにも対応できるのではないかと考えていたところです。

抽象的なメソッドは明示的に禁止されているわけではありません（私はしばしば代替表記を使います）。

そして、多重継承ができることは大きなプラスになると思います。

 
A100:
抽象的なメソッドは、明示的に禁止されているわけではありません。

ロッシュの 言葉を借りれば、薪を割るのは何のためなのか？

VonのFAQ は四畳半に座っていて、抽象メソッドや多重継承には無頓着です。

抽象的なメソッドがあってもなくても、プロジェクトの構造化という課題は解決されないのだ。

ちなみに、1つの実装バリエーションが多ければ多いほど、どのバリエーションを使うか選ぶのが難しくなります。

つまり、プログラマーがコードの美化という作業に行き詰まることが多いということがわかります。芸術のための芸術である。

一般的に（自分で言うのもなんですが）、プロジェクト計画のスタンプが多いほど楽だということに気がつきました。

そして、変更、修正、再修正、オーバーモディファイをすることがあります。

しかし、最初のフレームワークは（たとえそれが素晴らしいものでなくても）、ビルド全体のトーンを決めるものなのです。

 
Urain:

ロッシュの 言葉を借りれば、薪を割るのに役立つということですか？

そして、それを変更し、修正し、再修正し、過剰に修正することができるのです。

しかし、最初の枠組みは（たとえそれが素晴らしいものでなくても）、構築全体のトーンを設定するものです。

薪の製材スピードが上がります。

もし、あなたがすでに、どのように、何を見るべきかという明確なアイデアを持っているならば、おそらくMQL4ですべてをスマートに行うことができるでしょう。

そして、もしそのような概念がないのであれば、それは多くの変更と追加が行われることを意味します。また、多重継承により、最小限のコストで変更することができます。

抽象的なメソッドに賛成です。ちょうどいい記録の形になりますね。

 
A100:

薪の製材スピードが上がります。

もし、あなたがすでに、どのように、何を見るべきかという明確なアイデアを持っているならば、おそらくMQL4ですべてをスマートに行うことができるでしょう。

そして、もしそのような考えがないのであれば、それは多くの変更と追加を意味します。特に多重継承は、最小限のコストで変更することが可能です。

今、相続は放棄され、包摂が優先されつつある。多重相続に対する姿勢が想像できるでしょうか。
 
Vladix:
現在では、継承を放棄して包摂を優先させようとしています。多重相続に対する姿勢が想像できるでしょうか。
多重継承を行わないと、インターフェースレベルの水平関係を整理することができない。パラダイムは単純で、どんなオブジェクトも任意の数のインターフェイスをサポートすることができます。しかし、多重継承はそれ自体が悪であることは確かです。C#ではインターフェイスの利用が推奨されているのに禁止されているのは、そのためではあるまい。
 
Urain: FAQの 、四畳半に座っていて、抽象メソッドも多重継承も気にならないのがある 。


A narkarkal :https://www.mql5.com/ru/forum/13114
 

FAQ:

まさかね。

違うんです。スイッチを使って...ケースとステートマシンパターンを使用することは、異なるものです。引用した記事と同じで、パターンなんてないことは文面からわかる。

独自の勝利のシステムを発明した...」みたいなことが書いてあって、曲解されたマーチン文が書いてあるんです。

1...34567891011121314151617...20
新しいコメント