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

Nuevo comentario
 
George Merts:

Esta (y todas las que comienzan con guión bajo) es una función protegida de la clase.

Pues bien, ¡se han fusionado en uno!

Sólo hay una función - Compare(), pero tenemos que realizar una comparación por la clave que se pasa. En consecuencia, se elige una de las funciones particulares protegidas. Por eso están protegidos (protected), para que el usuario no pueda acceder a ellos - se llaman sólo desde Compare() y esto se indica con el subrayado.

Esta es también una de las reglas de diseño del código: una función que comienza con un guión bajo no está pensada para ser llamada por los usuarios, sólo sirve para ciertas tareas de la clase. El acceso a ella está restringido.

Pero para qué esos trucos de circo cuando es mucho más fácil hacerlo todo con los clásicos. Utiliza funciones envolventes y llaves para ocultar las variables y funciones anidadas y evitar el acceso a ellas y serás feliz. Sólo te confundirás a ti mismo y a los demás con estos protextos...

 
Andrei:

Pero para qué esos trucos de circo cuando todo es mucho más fácil de hacer a través de los clásicos. Utiliza funciones envolventes y llaves para ocultar las variables y funciones anidadas y evitar el acceso a ellas y serás feliz. Sólo te confundirás a ti mismo y a los demás con estos protextos...

No lo entiendo... Protegido es un modificador de acceso para una función. Es decir, se utiliza una función protectora a la que sólo se puede acceder desde una función de una clase o su descendiente. Además, el guión bajo significa para mí personalmente que hay algunas suposiciones implícitas que deben tenerse en cuenta al utilizarlo.

Dennis Kirichenko señaló correctamente que se podría escribir todo en una función Compare(). Pero entonces serían dos docenas de pantallas, sería poco realista verlo y más difícil de modificar que ahora.

He dejado sólo el selector de teclas en la función Compare(), mientras que el código que hace la comparación para las teclas particulares se coloca en funciones separadas. Como estas funciones son muy específicas del contexto, se declaran en la sección protegida de la clase, para que se pueda acceder a ellas exclusivamente desde otra función de la clase o descendiente. Y para recordar también que estas funciones están destinadas a realizar una tarea específica y estrecha dentro de otra función, las comienzo con un subrayado. Si en el futuro me encuentro con una función de este tipo, veré inmediatamente que hay suposiciones implícitas que hay que tener en cuenta al llamarla.

Parece que usted (vamos a referirnos a "usted") no sabe muy bien qué son los modificadores de acceso y por qué son necesarios.

 
George Merts:

No lo entiendo... Protegido es un modificador de acceso para una función. Es decir, se utiliza una función protectora a la que sólo se puede acceder desde una función de una clase o su descendiente. Además, el símbolo de subrayado para mí personalmente significa que hay algunas suposiciones implícitas a considerar cuando se utiliza.

Pues bien, se puede restringir el acceso a una función de forma clásica, sin necesidad de POO.
 
Artyom Trishkin:

Pero sin insultos personales...

Por favor, limpie el hilo de la inundación, deje sólo los mensajes educativosde Alexey Volchanskiy
 
Andrei:
Bueno, se puede limitar el acceso a la función por medios clásicos, sin ninguna OOP.

¿Cómo?

Esta es la tarea: hacer que en el futuro, al modificar el código, sea imposible tomar y utilizar una determinada función "en cualquier lugar". ¿Cómo hacerlo sin la restricción OOP delacceso al espacio de la clase con la ayuda de modificadores públicos-protegidos-privados?

 

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

En cuanto a la POO, muy interesante, ¿cómo sería la siguiente función, que tiene una amplia aplicación práctica (nada abstracta), en estilo procedimental?

Foro sobre comercio, sistemas de comercio automatizados y pruebas de estrategias

Organizar un ciclo de desbordamiento de pedidos

fxsaber, 2017.10.18 12:29

Versión sin referencia a la historia.
struct HISTORY_UNIT
{
  long Ticket;
  int Type;
  double Lots; 
    
  HISTORY_UNIT( void ) : Ticket(::OrderTicket()), Type(::OrderType()), Lots(::OrderLots())
  {
  }

  bool operator !=( const HISTORY_UNIT &Unit ) const
  {
    return((this.Ticket != Unit.Ticket) || (this.Type != Unit.Type) || (this.Lots != Unit.Lots));
  }
      
  bool IsChange( void )
  {
    const HISTORY_UNIT Tmp;
    const bool Res = (this != Tmp);
    
    if (Res)
      this = Tmp;
      
    return(Res);
  }
};

// Возвращает true только в случае, если с последнего вызова произошли торговые изменения
bool IsChange( void )
{
  static HISTORY_UNIT History[];  

  const int Total = OrdersTotal();  
  bool Res = (ArraySize(History) != Total);

  for (int i = 0, j = Res ? ArrayResize(History, 0, Total) : 0; i < Total; i++)      
    if (OrderSelect(i, SELECT_BY_POS))
    {
      if (Res || (Res = History[j].IsChange()))
        ArrayResize(History, j + 1, Total);
      
      j++;
    }
  
  return(Res);
}

Esta versión es especialmente relevante para MT5 en VPS, ya que MT5 es muy lento y costoso computacionalmente con Historia.

Obviamente cualquier OOP puede ser reescrito en estilo procedimental. Pero lo que me interesa es 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 y buena MT4.

 
Vladimir Pastushak:
Por favor, limpien este hilo de inundaciones, dejen sólo los posts educativosde Alexey Volchanskiy

Es tarde )))) sobre todo porque sólo podré encontrar tiempo este fin de semana, de repente resultó ser muy ocupado

Haré algunos estudios este fin de semana, tal vez algunos videos también.

 
Vladimir Pastushak:
Por favor, limpie el hilo de la inundación, deje sólo los mensajes educativosde Alexey Volchanskiy

Vladimir, si no has aprendido durante todos estos años, es demasiado tarde para empezar;).

 
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 se verí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 y buena MT4.

Te estás complicando demasiado incluso en este sencillo ejemplo. Siempre es más fácil reescribir la POO que meterse con el código de otros.... ¿Qué quieres hacer, al menos dímelo en lenguaje humano? Averigüe cuál es el cambio en el historial de pedidos.
 
Vasiliy Sokolov:

Vladimir, si en todos estos años todavía no han aprendido, creo que es demasiado tarde para empezar;)


¿Puedo preguntar quiénes son y qué no han aprendido? Los moderadores no han aprendido a limpiar o algo más ).

ZS: Por cierto, en todo el hilo no vi ni un solo deseo de abarcar ningún tema, como siempre, el roce de siempre. Así que he decidido grabar vídeos en YouTube desde cero sobre cómo funciona la POO, al menos será de alguna utilidad. De todos modos, en un tiempo la rama terminará en el branch_sucker.

12345678910111213...23
Nuevo comentario