OOPと手続き型プログラミングの比較 - ページ 5

新しいコメント
 
Petros Shatakhtsyan:

ここでは簡単な作業を紹介します（詳しく説明するとかなりの文章量になります）。

全てはOnTick()の中で行われます。例えば、ある条件を確認し、注文を出すとします。条件は問わないが、仮にある最大値か最小値とする。

ロボットは自然にチャートの上に立ち、このシンボルの相場を受け取ります。OnTickという関数だけでなく、OnTrade、OnTimer、カスタム関数など、他の関数があることは明らかです。

したがって、共有されるすべての変数は、コードの冒頭でこれらの関数の外で宣言されなければなりません。例えば、シンボル名、アスク、ビッド、スプレッド、気配値の桁数などです。何十本もあるでしょう。

このロボットは1つのシンボル、つまり立っている場所だけで取引します。このようなチャートが20枚あると仮定して、そのすべてに同じロボットをインストールして、20ペアすべてについて同時に取引することにします。

しかし、これはMarketの一部のトレーダーが指摘しているように、多通貨取引ロボットでは ありません。


ここでは、これを多通貨対応ロボットにする必要があります。つまり、どのチャートにも（1つのチャートにのみ）貼り付けて、20組の取引を開くことができます。テスターでソリタリーモードで起動し、Market Watchに登録されているペアで取引するということです。

ここでは、OOPを使わずにどのように実装するかを説明します。すべての共通変数を20要素の配列に変換するのでしょうか？

また、すべてのペアで同時に呼び出される関数についてはどうでしょうか。

OOPなしではやっていけない。:)


追伸：私はロシア語の教育を受けていないため、長文を書いてしまい、何ページも読む時間がなかったことをお断りしておきます。

多通貨エンジンを作るには、1つのペア用にカスタマイズされたロボットを再設計するのではなく、最初に多通貨エンジンを書く必要があります。

多通貨エンジンの作成方法は、OOPを使用する必要はありません。すべての通貨ペアのティックを取得し、同じ分析および注文関数を適用するコードのブロックをどこにでも書くことができます。オーダー関数自体には、ペアによって値が変化する変数が含まれる。これらの値は、ティックを受信するブロックによって変更されます。

 
Реter Konow:
具体的なタスクにつながることが望ましいと思います。この記述は、あまり明確ではありません。私の実践では、外部パラメータが変わってもアルゴリズムは変わりません。これらのパラメータがどのような値であっても、あらかじめ普遍化されています。したがって、何を言いたいのかよくわからない。具体的な例を挙げて説明してください。

例えば、1つのExpert Advisorに100のトレーリングストップのバリアントを詰め込む必要があります。プロシージャルなプログラミングをすると、こんな風にごちゃごちゃしてしまうんです。

if(Trailing_01_ON){
    Trailing1();
}

if(Trailing_02_ON){
    Trailing2();
}
...

...

...

if(Trailing_99_ON){
    Trailing99();
}

100個の同じコードの断片。プログラム実行時には、通常1つのトレイリングストップを含むだけです。 残りの99のifは、リソースを消費するだけです。

次に、OOPのバリエーションです。Expert Advisorの初期化では、トレイルの数に応じてポインタの配列をスケーリングし、含まれるトレイルに対してのみオブジェクトを生成します。その結果、以下のコードは常に動作するようになります。

for(int i=0;i<cnt;i++){
   p[i].Main();
}

トレーリングストップが1つでも有効であれば、cnt=1、つまり不要なものはないのです。

 
Dmitry Fedoseev:

ここで重要なのは、「どのように」ではなく、「なぜ」なのか、ということです。ターミナルにすでに実装されているものをなぜコード化するのか - 必要な数のチャートを開き、それらにEAを割り当てるだけでいいのです。さらに、シンボルや時間枠によってパラメータが異なる必要があります。


端末には何も実装されていない。第一に、チャートは20枚ではなく1枚しか開かれません。第二に、テスターでは、すべてのオープンポジションを 考慮し、同時に多くのペアをテストすることはできません。

まさか、「MarketWatchで選択した全シンボル」モードがあるのでしょうか。

 

オブジェクト "という概念がどのように記述されるかを理解していないプログラマは、現代のプログラミングの技術を知らないアマチュアプログラマと言えるでしょう。

 
Dmitry Fedoseev:

例えば、1つのExpert Advisorに100のトレーリングストップのバリアントを詰め込む必要があります。プロシージャルなプログラミングをすると、こんな風にごちゃごちゃしてしまうんです。

100個の同じコードの断片。プログラム実行中は、トレーリングストップのうち1つだけが有効になり、残りの99個のifはリソースを消費するだけです。

次に、OOPのバリエーションです。Expert Advisorの初期化では、トレイルの数に応じてポインタの配列をスケーリングし、含まれるトレイルに対してのみオブジェクトを生成します。その結果、以下のコードは常に動作するようになります。

1本のトレイリングバーが有効な場合は、cnt=1、つまり不要なものはありません。

これは、一般的にトレーリングを使った課題を解決するための、とてもとても奇妙なアプローチです。100種類のトレーリングストップがあり、それぞれに異なる機能がある、そんな仕事はないはずです。

これらのタイプを1つまたは複数の数式に圧縮して、1つの共通のトレーリングストップ関数を作る必要があります。以 上です。もちろん、グレーな作業をすることになりますが、OOPは関係ありませんから...。

 
Реter Konow:

トレーリングストップの問題に対して、全体として非常に、奇妙なアプローチです。トレーリングストップの種類は100種類もあって、それぞれに違う機能があるなんてことはないはずです。

これらのタイプは、1つまたはいくつかの数式と、1つの共通の末尾関数に圧縮する必要があります。以 上です。もちろん、グレーな作業をすることになりますが、OOPとは関係ありませんから...。


MAにトレーリングストップがついたとします、それも何十本もあります。

そして、簡単に生きられるのに、なぜ何かを圧縮するのか？
 
Dmitry Fedoseev:

トレーリングMAを想定してみますと、数十本のMAがあります。

そして、楽に暮らせるのに、なぜ何かを圧縮しなければならないのか。


OOPを支持するあなたの主張の本質は、本質的に馬鹿げた決定を促進することに基づいていることがわかりました。疑心暗鬼の論調である・・・。


なぜ何十種類もの末尾機能を搭載するのか？本格的なOOPプログラマーが普遍的な1本を書くのは難しいのでしょうか？

 
Реter Konow:


OOPを支持するあなたの主張の本質は、本質的に馬鹿げた解決策を促進することに基づいていることがわかりました。ダウトフルな議論...

なぜ急にバカバカしくなったのか？

ただ、100個のifを使うのは、どれだけバカバカしいことなのか。

 
Dmitry Fedoseev:

なぜ急にバカバカしくなったのか？

イフフォーを100個も使うのは馬鹿らしい。

イフフォーを100個も使う必要はない。もっと効率的に問題を解決して、異なるパラメータを末尾で調整しながら1つの関数にする必要があります。
 
Реter Konow:
ifofを100個も使う必要はない。より効率的にタスクを解決し、異なるパラメータに適応する末尾のユニットを持つ1つの関数を作る必要があります。

また、トレーリングストップを様々なパラメータに適応させるためにはどうすればいいのでしょうか？パラメータの組み合わせによっては、決して実行されないアルゴリズムの分岐がまだ残っています。

123456789101112...48
新しいコメント