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

 
Dmitry Fedoseev:

また、トレーリングを異なるパラメータに適応させるのはどうするつもりですか?

具体的なタスクで試してみましょう。もしあれば、提供してください。
 
Реter Konow:
できれば、具体的なタスクにつながるもの。このような記述は、あまり明確ではありません。私の実践では、外部パラメータを変えてもアルゴリズムは変わりません。これらのパラメータがどのような値であっても、あらかじめ普遍化されています。したがって、何を言いたいのかがよくわからない。具体的な事例で説明する。
class Ордер
{
  public: int SELL;

  Ордер(void) // Конструктор имеет то же имя, что и класс. Выполняется при инициализации переменной класса
  {
    SELL=0;
    int k=OrdersHistoryTotal()-1;
    for(; k>=0; k--)
    {
      if(!OrderSelect(k, SELECT_BY_POS, MODE_HISTORY)) continue;
      if(OrderType()==OP_SELL)SELL++;
    }
  }
}x;

void OnStart()
{
  Alert(x.SELL);
}

OOPのおかげで、メインのプログラムは非常に簡潔で分かりやすくなっています。これは、最初に思い浮かんだ例です。頻繁に注文数を 計算する必要がある場合、そのメリットは明らかです。最初はなかなか理解できないものです。しかし、関数も、パラメータがあっても、かつては難儀なものでした

 
Реter Konow:
それでは、あるタスクに挑戦してみましょう。ある場合は、ご提示ください。

具体的なタスク顧客は2つのMAのExpert Advisorを注文しており、それはコードベースで利用可能なすべてのトレーリングバリアントを含むが、テスターで遅くなることはないだろうと考えている。

また、EAは将来的に新しいトレーリングバリエーションに更新される見込みがあること(低コストで)。

 
STARIJ:

OOPのおかげで、メインのプログラムは非常に短く、明快です。これは、最初に思い浮かんだ例です。頻繁に注文数を 計算する必要がある場合、そのメリットは明らかです。最初はなかなか理解できないものです。しかし、関数も、パラメータがあっても、かつては難儀なものでした

よくわからないのですが、上記のループを常に行い、カウンタ値「SELL」を返す関数「int Number_orders()」を作ればいいのではないでしょうか?

例えば、こんな感じです。

 int Количество_ордеров()
  {
    SELL=0;
    int k=OrdersHistoryTotal()-1;
    for(; k>=0; k--)
    {
      if(!OrderSelect(k, SELECT_BY_POS, MODE_HISTORY)) continue;
      if(OrderType()==OP_SELL)SELL++;
    }
   return(SELL);
  }


なぜここに授業が必要なのか?

 
Dmitry Fedoseev:

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

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

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

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

関数名の配列を作り、インデックスから名前を選び、アクセスする。


OOPは関係ない。これは、彼らがOOPで解決しようとしている言語の限界である

 

私は試していませんが、例えばOOPがないとノンタイプの言語は作れないですよね。

 
Реter Konow:

なぜ、上記のループを常に行い、カウンターの値「SELL」を返す関数「int Number_orders()」を作らないのか理解できないのですが?

クラスを確定したことで、x.SELL x.BUY x.ALLと必要なものをすべて手に入れることができます。そして、それらに対応するのはとても簡単なことでしょう。OOPクラス - シンプルにするために
 
Dmitry Fedoseev:

具体的なタスク顧客は2つのMAのExpert Advisorを注文しており、それはコードベースで利用可能なすべてのトレーリングバリアントを含むが、テスターで遅くなることはないだろうと考えている。

そして、将来的に新しい後続のバリエーションを追加できる見込みがあること(高価ではない)。

なるほど、これは紛れもないOOP賛成論ですね。顧客のバカさ加減とそれに対抗する時間のなさ、他人のアルゴリズムを改善する気のなさ(笑)はい、この場合はOOPが必要です。同感です)。
 
STARIJ:
クラスを絞り込むことで、x.SELL x.BUY x.ALLと必要なものを手に入れることができます。そして、それらに対応するのはとても簡単なことでしょう。OOPクラス - シンプルにするために
この関数を細かく調整することで、これらと同じ変数をすべて配列にして、この関数に渡すことができます。そして、意図したとおりに使う...。
 
СанСаныч Фоменко:

関数名の配列を作り、インデックスから名前を選び、呼び出す。


OOPとは関係ない。これは、彼らがOOPの力を借りて解決しようとしている言語の限界である。

文字列として定義された名前による関数呼び出しはありません。そして、それが存在する言語では、テーブルのハッシュによって行われる、つまり、ひどいハンディキャップなのです。

この問題を解決する通常の方法は、関数へのポインタを使用 することです(これについては、こちらに書きました)。しかし、なぜポインタだけを使うのか。もっと便利な方法がある。関数ポインタを活用するだけでなく、データやコードを便利に構造化できるOOPがあるのだ。