ラウンジでPLOについて語る - ページ 9

新しいコメント
 
fxsaber:

どうやらstaticとconst（これはOOPではない）は必要ないようです。

OOPに関しては、次のような実用性の高い（抽象的でない）関数が手続き型になるとどうなるのか、非常に興味深いですね。

もちろん、どんなOOPも手続き型に書き換えることは可能です。でも、練習には興味があります。そこで、OOPも最低限使われている上記のような小さなコードをとってみました。

では、この例で、手続き型はOOPと比較して、どれだけすっきりしているか／便利か／読みやすいか／正しいか？さて、数ページにわたって話をするわけではありませんが、短いソースコードの手続き型とOOPを比較するだけです。OOPの対戦相手には、名人芸を見せてもらう。これは、恐るべきMT5ではなく、古き良きMT4です。

私はOOPに反対しているわけではありません。ただ、品質が悪く、暗号化されたコードの1つです。(私はOOPの反対者ではなく、質の悪い不可解なコードの反対者です。）

#define  MC 200
#define  MYOWNSELECT        OrderSelect     
#define  MYOWNTICKET        OrderTicket
#define  MYOWNOTIPE         OrderType
#define  MYOWNOLOT          OrderLots
// Возвращает true только в случае, если с последнего вызова произошли торговые изменения
bool IsChanged_NoOOP_Cryptic_aka_fxsaber(void)
{
  static int ptot=0,tickets[MC],types[MC];
  static double lots[MC];

  int total;
  bool res=ptot!=(total=::OrdersTotal());

  for(int i=0,j=0; i<total; i++)
     if(MYOWNSELECT(i,SELECT_BY_POS))
     {
       if(res=(res || (tickets[j]!=MYOWNTICKET() || types[j]!=MYOWNOTIPE() || lots[j]!=MYOWNOLOT())))
       {
         tickets[j]=MYOWNTICKET();
         types[j]=MYOWNOTIPE();
         lots[j]=MYOWNOLOT();
       }

       j++;
     }
  ptot=total;

  return(res);
}
 
Dennis Kirichenko:

大変申し訳ないのですが、どの言語の文脈でこの結論を出しているのでしょうか？:-)




デニス、フォーラムの文脈で ))))))))))))))))))))))))))))))))))))))))))))

 
Alain Verleyen:

私はOOPに反対しているわけではありません。ただ、品質が悪く、暗号化されたコードの1つです。(私はOOPの反対者ではなく、質の悪い暗号化されたコードの反対者です。）

プロシージャルなコードをありがとうございました少し手を加えました。

#define  MC 200
#define  MYOWNSELECT        OrderSelect     
#define  MYOWNTICKET        OrderTicket
#define  MYOWNOTIPE         OrderType
#define  MYOWNOLOT          OrderLots
// Возвращает true только в случае, если с последнего вызова произошли торговые изменения
bool IsChanged_NoOOP_Cryptic_aka_fxsaber(void)
{
  static int ptot=0,tickets[MC],types[MC];
  static double lots[MC];

  int total;
  bool res=ptot!=(total=::OrdersTotal());

  int j = 0;
  
  for(int i=0; i<total; i++)
     if(MYOWNSELECT(i,SELECT_BY_POS))
     {
       if(res=(res || (tickets[j]!=MYOWNTICKET() || types[j]!=MYOWNOTIPE() || lots[j]!=MYOWNOLOT())))
       {
         tickets[j]=MYOWNTICKET();
         types[j]=MYOWNOTIPE();
         lots[j]=MYOWNOLOT();
       }

       j++;
     }
  ptot=j;

  return(res);
}


それぞれの解決策（OOP-solution）の長所と短所を、自分の目で確認できるようになりました。誰もが自分の選択をするのであって、異なる視点を押し付けるのは愚かなことです。

 
Dennis Kirichenko:

大変申し訳ないのですが、どの言語の文脈でこの結論を出しているのでしょうか？:-)

もちろん、プロについて。

 
fxsaber:

プロシージャルなコードをありがとうございました少し手を加えた

コンパクトさも微調整できることを明確にするためです。

#define  MC 200
#define  MYOWNSELECT        OrderSelect     

bool IsChanged_NoOOP_Cryptic_aka_fxsaber(void)
{
  static int ptot=0;
  static string History_Unit[MC];

  string Order_Data;
  int total;
  bool res=ptot!=(total=::OrdersTotal());
  int j = 0, i = total;
  
  while(i-- > 0)
     if(MYOWNSELECT(i,SELECT_BY_POS))
     {
       Order_Data = StringFormat("%u|%u|%.2f", OrderTicket(), OrderType(), OrderLots());
       if(res=(res || History_Unit[j]!=Order_Data)) History_Unit[j]=Order_Data;

       j++;
     }
  ptot=j;

  return(res);
}

もちろん、構造体／配列／行を比較したときに、どれだけパフォーマンスが変わるかを確認することもできます。しかし、それは問題の一端を切り取ったものなので、意味がありません

PS そして、私はOOPに反対しているわけではありません。ご都合主義に賛成。

 
Alexander Puzanov:

コンパクトさも微調整できることを明確にするためです。

もちろん、構造体／配列／行を比較したときに、 どれだけパフォーマンスが 変わるかを確認することもできます。しかし、これは文脈から取り出されたちょっとした作業なので、意味がありません

PS そして、私はOOPに反対しているわけではありません。ご都合主義に賛成。

崩壊！？

 
Alexander Puzanov:

コンパクトさも微調整できることを明確にするためです。

もちろん、構造体／配列／行を比較したときに、どれだけパフォーマンスが変わるかを確認することもできます。しかし、それは問題の一端を切り取ったものなので、意味がありません

PS そして、私はOOPに反対しているわけではありません。ご都合主義に賛成。

DEFINEを使ったのは冗談です ;-)アプローチは非常にゆっくりしたものになりますね。(DEFINEの使用は冗談です。) あなたのアプローチは非常に遅くなるでしょう)

 
Alain Verleyen:

DEFINEの使用は冗談です ;-)アプローチは非常にゆっくりです。(DEFINEの使用は冗談です。) あなたのアプローチは非常に遅くなるでしょう)

もちろんです。これも冗談で、コード美化のパレードですよね？

これもジョークです。コンパクトさとわかりやすさを優先したひねりが効いています

---

fxsaber

崩壊している！？

特定の実装、特定のケースの測定である

 
Alexander Puzanov:

もちろんです。これもジョークですね。これはコード美化のパレードですね。

(残念ながらまだジョークをキャッチできていません;-)

はい、本当に素敵です。私は残念ながらまだジョークをキャッチすることができません;-)

 
fxsaber:

それぞれのソリューション（OOPソリューション）の長所と短所が、自分の目で確認できるようになったのです。誰もが自分の選択をするのであって、異なる視点を押し付けるのは愚かなことです。

押し付ける必要はないが、手続き型では余計なジェスチャーをしなくてもコードの論理がすでに見えていることは明らかであり、雇われプログラマーのジェスチャー一つ一つが雇用主にとってコストになる。したがって、雇用主が賢ければ、OOPに騙されることはありませんが、賢いプログラマーは、雇用主のリテラシーの低さを利用して、より多くのお金を得るために進歩的なOOPについての物語をねじ曲げることができます。:)

12345678910111213141516...23
新しいコメント