Conversando sobre a OLP no salão - página 9

 
fxsaber:

Aparentemente estáticas e constantes (isto não é OOP) não são necessárias.

Quanto ao OOP, é muito interessante como a próxima função, que tem ampla aplicação prática (não abstrata de forma alguma), pareceria em estilo processual?

Obviamente, qualquer OOP pode ser reescrito em estilo processual. Mas eu estou interessado na prática. Assim, eu levei o código acima, onde o OOP também é usado ao mínimo.

Então, quanto mais agradável/muito conveniente/muito legível/muito correto é o estilo de procedimento em comparação com o OOP neste exemplo? Bem, não para falar por algumas páginas, mas apenas para comparar o procedimento de código fonte curto com o OOP. Peço aos oponentes do OOP que mostrem uma classe mestra. Este não é o temido MT5, mas o bom e velho MT4.

Eu não sou contra o OOP. Apenas um de má qualidade e código críptico. (Não sou um oponente do OOP. Apenas um de má qualidade e código críptico)

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

Lamento muito, no contexto de que linguagem você está tirando esta conclusão? :-)




Denis, no contexto do fórum ))))))))))

 
Alain Verleyen:

Eu não sou contra a OOP. Apenas um de má qualidade e código críptico. (Não sou um oponente do OOP. Apenas um de má qualidade e código críptico)

Obrigado pelo código de procedimento! Afinou um pouco.

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


Prós e contras de cada uma das soluções(OOP-solução) que você pode agora ver com seus próprios olhos. Cada um faz sua própria escolha e é uma bobagem impor um ponto de vista diferente.

 
Dennis Kirichenko:

Lamento muito, no contexto de que linguagem você está tirando esta conclusão? :-)

Sobre os profissionais, é claro.

 
fxsaber:

Obrigado pelo código de procedimento! Ajustou um pouco

Para deixar claro que a compacidade também pode ser ajustada.

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

Você poderia, é claro, ver o quanto o desempenho mudaria ao comparar estruturas/arrays/rows. Mas esta é uma tarefa um pouco fora do contexto, então não há sentido

PS E eu não sou contra o OOP. A favor do expediente.

 
Alexander Puzanov:

Para deixar claro que a compacidade também pode ser ajustada.

Você poderia, é claro, ver o quanto o desempenho mudaria ao comparar estruturas/arrays/rows. Mas esta é uma tarefa um pouco fora do contexto, então não há sentido

PS E eu não sou contra o OOP. A favor do expediente.

Colapso!

 
Alexander Puzanov:

Para deixar claro que a compacidade também pode ser ajustada.

Você poderia, é claro, ver o quanto o desempenho mudaria ao comparar estruturas/arrays/rows. Mas isso é um pedaço do problema retirado do contexto, então não há sentido

PS E eu não sou contra o OOP. A favor do expediente.

Usar DEFINE foi uma piada ;-) Sua abordagem seria muito lenta. (O uso de DEFINE foi uma piada ;-) Sua abordagem será muito lenta).

 
Alain Verleyen:

O uso de DEFINE foi uma piada ;-) Sua abordagem será muito lenta. (O uso do DEFINE foi uma piada ;-) Sua abordagem será muito lenta).

Claro. Isto também é brincadeira - é um desfile de embelezamento de código, não é?

Também é uma piada - uma reviravolta em favor da compacidade e clareza

---

É uma medida de uma implementação particular, um caso particular

 
Alexander Puzanov:

Claro. Isto também é brincadeira - é um desfile de beleza em código, não é?

Sim, muito legal.(infelizmente ainda não estou apto a pegar piada ;-)

Sim, muito bom. Infelizmente ainda não estou apto a pegar piada ;-)

 
fxsaber:

Os prós e os contras de cada solução(a solução OOP) podem agora ser vistos por si mesmos. Cada um faz sua própria escolha e é uma bobagem impor um ponto de vista diferente.

Não há necessidade de impor, mas é óbvio que em uma forma processual a lógica do código já é visível sem gestos extras, e cada gesto de um programador contratado custa dinheiro para o empregador. Portanto, se um empregador é inteligente, ele não será enganado pelo OOP, mas um programador inteligente pode distorcer uma história sobre o OOP progressivo para obter mais dinheiro dele, aproveitando sua baixa alfabetização. :)