Hablando de la OLP en el salón - página 9

Nuevo comentario
 
fxsaber:

Aparentemente static y const (esto no es OOP) no son necesarios.

En cuanto a la programación orientada a objetos, es muy interesante cómo sería la siguiente función, que tiene una amplia aplicación práctica (nada abstracta), en estilo procedimental...

Obviamente, cualquier OOP puede ser reescrito en estilo procedimental. Pero me interesa la práctica. Así que tomé el diminuto código anterior, en el que también se utiliza la POO al mínimo.

Entonces, ¿cuánto más bonito/más cómodo/más legible/más correcto es el estilo procedimental comparado con la POO en este ejemplo? Bueno, no para hablar durante unas cuantas páginas, pero sólo para comparar el código fuente corto procedural vs OOP. Pido a los opositores de OOP que muestren una clase magistral. No se trata de la temida MT5, sino de la vieja MT4.

No estoy en contra de la OOP. Sólo uno de mala calidad y código críptico. (No soy un opositor de la POO, sólo de la mala calidad y el 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:

Lo siento mucho, ¿en el contexto de qué idioma está sacando esta conclusión? :-)




Denis, en el contexto del foro ))))))))))

 
Alain Verleyen:

No estoy en contra de la OOP. Sólo uno de mala calidad y código críptico. (No soy un opositor de la POO, sólo de la mala calidad y el código críptico)

Gracias por el código de procedimiento. Lo he retocado un poco.

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


Los pros y los contras de cada una de las soluciones(OOP-solución) los puedes ver ahora con tus propios ojos. Cada uno hace su propia elección y es una tontería imponer un punto de vista diferente.

 
Dennis Kirichenko:

Lo siento mucho, ¿en el contexto de qué idioma está sacando esta conclusión? :-)

Sobre los profesionales, por supuesto.

 
fxsaber:

¡Gracias por el código de procedimiento! Lo he retocado un poco

Para que quede claro que la compacidad también se puede ajustar.

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

Por supuesto, podrías ver cuánto cambiaría el rendimiento al comparar estructuras/arreglos/filas. Pero eso es una parte del problema sacada de contexto, así que no tiene sentido

PS Y no estoy en contra de la OOP. A favor de la conveniencia.

 
Alexander Puzanov:

Para que quede claro que la compacidad es otra cosa que hay que retocar

Por supuesto, podrías ver cuánto cambiaría el rendimiento al comparar estructuras/arreglos/filas. Pero esto es una tarea un poco sacada de contexto, así que no tiene sentido

PS Y no estoy en contra de la OOP. A favor de la conveniencia.

¡Colapso!

 
Alexander Puzanov:

Para que quede claro que la compacidad es otra cosa que hay que retocar

Por supuesto, podrías ver cuánto cambiaría el rendimiento al comparar estructuras/arreglos/filas. Pero esto es una tarea un poco sacada de contexto, así que no tiene sentido

P.D. Y no estoy en contra de la OOP. A favor de la conveniencia.

El uso de DEFINE era una broma ;-) Su enfoque sería muy lento. (El uso de DEFINE era una broma ;-) Su enfoque será muy lento).

 
Alain Verleyen:

El uso de DEFINE era una broma ;-) Su aproximación será muy lenta. (El uso de DEFINE era una broma ;-) Su enfoque será muy lento).

Claro que sí. Esto también es un chiste: es un desfile de embellecimiento del código, ¿no?

También es una broma: un giro a favor de la compacidad y la claridad

---

fxsaber:

¡Se está derrumbando!

Es una medida de una implementación particular, un caso particular

 
Alexander Puzanov:

Claro que sí. Esto también es un chiste, es un desfile de belleza en código, ¿no?

Sí, muy bonito.(por desgracia, aún no he podido pillar el chiste ;-)

Sí, muy bonito. Por desgracia, aún no he podido pillar la broma ;-)

 
fxsaber:

Los pros y los contras de cada solución(la solución OOP) pueden verse ahora por sí mismos. Cada uno hace su propia elección y es una tontería imponer un punto de vista diferente.

No hace falta imponerlo, pero es obvio que de forma procedimental la lógica del código ya es visible sin gestos extra, y cada gesto de un programador contratado cuesta dinero al empleador. Por lo tanto, si un empresario es inteligente, no se dejará engañar por la POO, pero un programador astuto puede tergiversar un cuento sobre la POO progresiva para sacarle más dinero aprovechándose de su baja alfabetización. :)

12345678910111213141516...23
Nuevo comentario