Разговоры на завалинке о ООП - страница 9

Новый комментарий
 
fxsaber:

По всей видимости, static и const (это не ООП) не нужны.

Что же касается ООП, то очень интересно, как будет выглядеть в процедурном стиле следующая, имеющая широкое практическое применение (совсем не абстрактная), функция?

Очевидно, что любой ООП можно переписать в процедурном стиле. Но интересует практика. Поэтому взял вышеприведенный крохотный код, где и ООП используется по минимуму.

Так насколько красивее/удобнее/читабельнее/правильнее процедурный стиль по сравнению с ООП будет в данном примере? Ну чтобы не голословить несколько страниц, а просто сравнить короткие исходники процедурный vs ООП. Прошу противников ООП показать мастер-класс. Это не страшный MT5, а старый добрый MT4.

Я не против ООП. Только один из плохого качества и загадочный код. (I am not an opponent of OOP. Just one of bad quality and cryptic code)

#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:

Я не против ООП. Только один из плохого качества и загадочный код. (I am not an opponent of OOP. Just one of bad quality and cryptic code)

Спасибо за процедурный код! Немного подправил

#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);
}


Плюсы и минусы каждого из решений (ООП-решение) можно теперь воочию лицезреть. Каждый делает для себя свой выбор и навязывать иную точку зрения просто глупо. 

 
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);
}

Можно, конечно, посмотреть насколько существенно изменится быстродействие при сравнении структур/массивов/строк. Но это кусочек задачи, вырванной из контекста, so смысла нет

PS И я не против ООП. За целесообразность

 
Alexander Puzanov:

Для наглядности с компактностью можно ещё чего-нибудь подправить

Можно, конечно, посмотреть насколько существенно изменится быстродействие при сравнении структур/массивов/строк. Но это кусочек задачи, вырванной из контекста, so смысла нет

PS И я не против ООП. За целесообразность

Рухнет!

 
Alexander Puzanov:

Для наглядности с компактностью можно ещё чего-нибудь подправить

Можно, конечно, посмотреть насколько существенно изменится быстродействие при сравнении структур/массивов/строк. Но это кусочек задачи, вырванной из контекста, so смысла нет

PS И я не против ООП. За целесообразность

Использование DEFINE было шуткой ;-) Ваш подход будет очень медленным. (Usage of DEFINE was a joke ;-)  Your approach will be very slow.)

 
Alain Verleyen:

Использование DEFINE было шуткой ;-) Ваш подход будет очень медленным. (Usage of DEFINE was a joke ;-)  Your approach will be very slow.)

Sure. This is joke too - this is a code beautiness parade, isn't it?

Это тоже шутка - выкрутас в пользу компактности и наглядности

---

fxsaber:

Рухнет!

Это же замер конкретной реализации, частный случай

 
Alexander Puzanov:

Sure. This is joke too - this is a code beautiness parade, isn't it?

Yes really nice.  (I am not able to catch joke yet unfortunately ;-)

Да, действительно приятно. К сожалению, я не в состоянии поймать шутку ;-)

 
fxsaber:

Плюсы и минусы каждого из решений (ООП-решение) можно теперь воочию лицезреть. Каждый делает для себя свой выбор и навязывать иную точку зрения просто глупо. 

Навязывать не надо, но очевидно что в процедурном виде уже просматривается логика кода без лишних телодвижений, а каждое телодвижение наемного программиста стоит работодателю денежку. Поэтому если работодатель не дурак, то он не поведется на ООП, но зато хитрый программист может ему навешать лапшу про прогрессивность ООП чтобы срубить с него побольше воспользовавшись его малограмотностью. :)

12345678910111213141516...23
Новый комментарий
Причина обращения: