Gastos generales de la OLP - página 4
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
Mi experiencia demuestra que sí es necesario.
Yo hice este camino hace unos cinco años, por aquel entonces en MT4. (No porque no supiera de POO, sino porque me daba pereza molestarme con las interfaces y la herencia, sobre todo porque en ese momento MT4 y MT5 eran significativamente diferentes en cuanto a la implementación de MQL). Esto me llevó a comprender su falacia. No es una "sabiduría", sino una limitación bastante razonable, una especie de "a prueba de tontos". Si siempre recuerdas de qué es responsable cada uno de los cientos de variables, no necesitas la encapsulación. No lo recuerdo, y prefiero tener el menor número posible de entidades disponibles en cada bloque de un programa.
Tan pronto como apareció MQL4 OOP - empecé a traducir todos mis desarrollos en una sola forma basada en interfaces.
Todavía no he conseguido encontrar algo más conveniente que el sistema MQL4-order. Si tienes un ejemplo, por favor, muéstramelo.
Todas las API de comercio que he visto parecen monstruosas en comparación con MQL4. También son torpes.
Nunca se me ha ocurrido nada más cómodo que un sistema de pedidos MQL4. Si tienes un ejemplo, por favor, muéstramelo.
Todas las API de comercio que he visto parecen monstruosas en comparación con MQL4. Y lo que es más, son torpes.
Qué bien va a salir de esto, cada parámetro debe ser dibujado en una función separada. Sería más lógico recibir la estructura con todos los parámetros por petición, como con los ticks.
Nunca se me ha ocurrido nada más cómodo que un sistema de pedidos MQL4. Si tienes un ejemplo, por favor, muéstramelo.
Todas las API de comercio que he visto parecen monstruosas en comparación con MQL4. Y lo que es más, son torpes.
¿Qué quieres decir?
La esencia misma de las órdenes... Sí, estoy de acuerdo, es bastante útil.
Pero sólo la aplicación de la POO a este sistema, en mi opinión, es lo que da la mayor "ganancia". Digamos que tengo la misma interfaz - da tanto la posición de MT4 que consiste en órdenes como la posición de MT5 que consiste en posiciones de MT5, e independientemente de las condiciones de cobertura o de compensación.
En mi opinión, es mucho más lógico y comprensible cuando tenemos una lista de objetos de órdenes (o posiciones de MT5) obtenida a través de la función Select() y nos dirigimos a las propiedades de las órdenes, en lugar del"estado del entorno" (obtenido a través de la misma función), que abordamos a través de funciones.
Lo más interesante es que si necesitamos hacer un seguimiento de varios pedidos a la vez -en este caso, el enfoque procedimental nos lleva inevitablemente a un "pseudo-objeto"- tenemos que crear un array de información sobre los pedidos que debe actualizarse al entrar en OnTick() y trabajar con los datos de los pedidos por índices en el array, al igual que con los punteros OOP a los objetos de los pedidos.
Además, el enfoque OOP nos daría una ventaja al trabajar con órdenes históricas y activas simultáneamente, ya que la interfaz de la orden histórica es la sucesora de la orden activa. Además, el enfoque procedimental implica que las órdenes históricas y las activas son tratadas por funciones diferentes, lo cual es mucho menos conveniente.
Lo bueno es que cada parámetro tiene que ser tirado por una función separada. Lo lógico sería obtener la estructura con todos los parámetros a petición, al igual que con los ticks.
Las entradas Order.TakeProfit y OrderTakeProfit() son las mismas. El primero sólo tiene la posibilidad de almacenar el objeto, y el segundo - la relevancia. La necesidad de almacenar se satisface muy raramente, y no en TS. Y ahí no hay problema para crear la estructura.
Yo mismo me he preguntado por qué los desarrolladores no han hecho la devolución de la estructura del pedido, y han dejado cada campo por separado a través de una función (para el historial también se requiere un ticket cada vez).
En general, no veo nada realmente malo en MQL4-API (puede funcionar no sólo en MT4/5).
¿Qué quieres decir?
La esencia misma de los oficios del orden ? Sí, estoy de acuerdo, muy útil.
Pero sólo la aplicación de la POO a este sistema -en mi opinión- es lo que da la mayor "ganancia". Digamos que tengo la misma interfaz - da tanto la posición de MT4 que consiste en órdenes como la posición de MT5 que consiste en posiciones de MT5, e independientemente de si está cubierto o compensado.
Tú tienes tu propia envoltura, el otro tiene la suya. La pregunta era si es posible crear una envoltura más conveniente que MQL4.
Es mucho más lógico y comprensible en mi opinión, cuando tenemos una lista de objetos de orden (o posiciones de MT5) obtenida mediante la función Select() y accedemos a las propiedades de la orden en lugar del"estado del entorno" (obtenido mediante la misma función) al que accedemos mediante funciones.
Lo más interesante es que si necesitamos hacer un seguimiento de varios pedidos a la vez -en este caso, el enfoque procedimental nos lleva inevitablemente a un enfoque de "pseudo-objeto"- tenemos que crear un array de información sobre los pedidos que debe ser actualizado al entrar en OnTick() y manejar los datos de los pedidos por índices en el array de la misma manera que manejamos los punteros OOP a los objetos de los pedidos.
Ya escribí sobre ello en el post anterior.
Además, el enfoque OOP nos daría una ventaja a la hora de trabajar con órdenes históricas y activas simultáneamente, ya que la interfaz de una orden histórica es heredera de una orden activa. La mayoría de las funciones son comunes. Además, el enfoque procedimental nos permite manejar las órdenes históricas y las activas utilizando funciones diferentes, lo que es mucho menos conveniente.
Bueno, en MQL4, el historial se maneja con las mismas funciones (OrdersHistoryTotal no cuenta).
Estaría bien tener un ejemplo de código en el que la propia API de comercio sea claramente mejor que la MQL4-API. Yo mismo utilizo OOP en casi todas partes. Y para algunas tareas específicas hago algunas envolturas comerciales. Pero no son universales, aunque sí muy convenientes para alguna tarea en particular. Sin embargo, todavía quiero comparar las APIs de comercio universal.
Yo mismo me he preguntado por qué los desarrolladores no han hecho de la devolución del pedido una estructura, sino que han dejado cada campo individualmente a través de una función (también se requiere un ticket cada vez para el historial).
Alexey Volchanskiy:
Дело в том, что в МТ4 до 600-го билда не было структур )) А новый MQL4 появился где-то в начале 2013 г.
En MT5 había estructuras, pero los retornos a través de funciones todavía.
Foro sobre comercio, sistemas de comercio automatizados y pruebas de estrategias
Gastos generales de OOP
fxsaber, 2017.07.07 08:08
La pregunta era otra, ¿es posible crear un wrapper más conveniente que MQL4?
En MT5 había estructuras, pero devuelven a través de funciones de todos modos.
Tal vez decidieron no romper la tradición, pero deberían haberlo hecho.
Entiendo que si los datos se descargan del servidor de la empresa de corretaje, pero es local, se toma al instante, podríamos llenar la estructura inmediatamente
Probablemente decidieron no romper la tradición, aunque deberían haber
Entiendo que si los datos se descargaran del servidor de DC, pero son locales, se toman al instante, se podría llenar la estructura inmediatamente
Sí, durante el SELECT sólo rellenamos una instancia de una estructura oculta, a cuyos campos sólo se puede acceder mediante funciones const(read-only).
Esta es probablemente la única solución central cuestionable de la API de comercio. Por lo demás, no sé ni de qué quejarme.
Sí, cuando se utiliza SELECT, se llena una instancia de una estructura oculta a cuyos campos sólo se puede acceder mediante funciones const(read-only).