在休息室谈论巴解组织的问题 - 页 9

新评论
 
fxsaber:

显然，静态和常量（这不是OOP）是不需要的。

至于OOP，非常有趣的是，下面这个具有广泛实际应用（根本不是抽象的）的功能在程序式中会是什么样子？

很明显，任何OOP都可以用程序化的方式重写。但我对实践感兴趣。所以我把上面的小代码，其中的OOP也用到了最小。

那么，在这个例子中，与OOP相比，程序式有多好/多方便/多可读/多正确呢？好了，不说几页了，只想比较一下短的源代码程序化与OOP。我要求OOP的对手展示一个大师级 的作品。这不是可怕的MT5，而是古老的MT4。

我并不反对OOP。只是一个质量差、代码隐蔽的人。(我不是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。只是一个质量不好，代码隐蔽的人。(我不是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-解决方案）的优点和缺点，你现在可以亲眼看到。每个人都有自己的选择，强加不同的观点是愚蠢的。

 
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
新评论