Gastos generales de la OLP - página 3
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
1. Por ejemplo, necesitas un array de objetos.
Puedes hacerlo de forma procedimental, o puedes hacerlo basándote en CArrayObj y CObjest. Los problemas empiezan cuando necesitas cambiar el comportamiento de, por ejemplo, añadir o eliminar objetos, o clasificarlos. En la programación orientada a objetos (OOP), el soporte para un array de punteros en sí mismo y para trabajar con él está incluido en los objetos base. La modificación de los objetos descendientes que realmente están contenidos en el array no afecta a nada. En el estilo procedimental -modificar objetos reales que están realmente contenidos en un array- suele afectar a muchos más lugares, al menos porque tenemos que considerar los cambios en el tamaño de los objetos. Lo que llevará mucho más fácilmente a errores.
2. Multiplataforma - también es mucho más conveniente organizar en estilo OOP. Cuando en la solicitud, digamos, una posición de comercio - obtenemos una interfaz, y no importa en qué plataforma trabajamos - la interfaz ofrece funciones virtuales, en la que puede obtener todos los datos sobre todas las órdenes (para MT4) o posiciones (MT5), y, desde el punto de vista de los expertos - no hay ninguna diferencia. El Asesor Experto no necesita saber en qué plataforma trabaja.
3. Pues bien, "terminar en la programación procedimental" es "escribir objetos-procedimientos", es decir, la creación de unos vínculos entre los datos y los procedimientos, que representan objetos en la POO.
4. Y luego tenemos, digamos, una serie de tipos de órdenes, que tienen mucho en común. Sería razonable hacer un objeto COrderInfo - que sería el objeto base, y sus herederos representarían diferentes tipos de órdenes. En ese momento, el procesador de operaciones (tengo la clase CTradeProcessor) apoyará automáticamente exactamente esa orden, que se le ha pasado, por aquellos procedimientos que se requieren para procesar esa orden.
5.Es más fácil atrapar los errores donde hay menos enlaces cruzados. Esto se garantiza mediante la encapsulación y el polimorfismo. Solicitamos la interfaz de la posición comercial (CTradePositionI) y todas las conexiones con las clases reales, que representan esta posición (CMT4PositionInfo,CMT5PositionInfo) se realizan sólo a través de esta interfaz, que sólo contribuye a una corrección de errores más fácil, que si trabajamos directamente con las funciones reales que devuelven los datos de la posición comercial.
1. ¿Para qué?
¿Por qué no se puede compilar la misma función en diferentes plataformas?
3. la idea era empaquetar el texto de las funciones por el tipo de estructura para que fuera más cómodo referirse a ellas por analogía con la referencia a una función como miembro de una clase. En principio, no es necesario crear ningún objeto para ello.
4. Sería más razonable hacer una sola función con sus ajustes, en lugar de multiplicar varios objetos y conexiones innecesarias a través de interfaces.
5. Además, todos estos enlaces deben ser programados y luego rastreados a través de las interfaces y similares, donde los errores pueden ser difíciles de detectar. Esta ocupación es innecesaria y sin sentido desde el principio.
1. Por ejemplo, ¿para qué?
2. ¿Por qué no se puede compilar la misma función en diferentes plataformas para no tener que crear interfaces para ella?
Me refería a empaquetar el texto de las funciones por el tipo de estructura para un acceso más conveniente, similar a dirigir una función como un miembro de la clase. En principio, no se creará ningún objeto con este fin.
4. Es más inteligente hacer una sola función con ajustes en lugar de multiplicar varios objetos y conexiones innecesarias a través de interfaces.
5. Además, todos estos enlaces deben ser programados y luego rastreados a través de las interfaces y similares, donde los errores pueden ser difíciles de detectar. Esta ocupación es innecesaria y sin sentido desde el principio.
1. Bueno, la clase CTradePosition es esencialmente una lista de órdenes abiertas. Y para ellos, sería muy útil tener una interfaz, una clase base y clases reales.
2. Sólo hay una interfaz. Para todas las plataformas. Y en el caso de la OOP, no pensamos realmente en dónde estamos trabajando. No tenemos que considerar cosas que dependen de la plataforma y del orden.
¿Y cuál es la diferencia entre un objeto y una función en este embalaje? Eso es lo que estoy diciendo - es esencialmente la misma cosa. En el caso de un objeto - también se añade una función constructora automática, sin embargo, por defecto - está vacía.
4. Exactamente, esta misma "función única con ajustes" es el origen de los problemas. Porque suele haber muchos ajustes. Y no están dispersos en diferentes niveles de la jerarquía de clases, sino concentrados en esta misma función. Pero la interfaz permite dejar "fuera de consideración" todas las configuraciones que no se utilizan en un contexto determinado - lo que tiene un efecto muy bueno en la comprensión del código y las posibilidades de errores y su detección. Esta es exactamente la principal ventaja de la POO - toda la funcionalidad está "dispersa" en objetos en diferentes niveles jerárquicos y cuando se trabaja con tal o cual parte de ella - otros no interfieren. En cambio, en una función única con ajustes, toda la funcionalidad está siempre disponible, aunque sea superflua. Esto suele ser una fuente de problemas simplemente porque se pueden mezclar accidentalmente las variables. La principal desventaja es que es mucho más difícil detectar errores en una función tan única.
5. en cualquier caso, estos enlaces son necesarios y deben ser programados - son, de hecho, los mismos ajustes en una sola función. Por ejemplo, en mi ejemplo - en una sola función tenemos acceso a la diferencia de plataformas, diferentes tipos de orden, diferencia en la representación de la posición - todo esto tiene que ser tomado en cuenta. Y cuando hay una interfaz, todo está "cortado": sólo se puede tener en cuenta lo que está definido en la interfaz.
Ese es el objetivo de la encapsulación, limitar el acceso de un bloque de código a otro bloque. Por el contrario, sugieres tener "una gran función universal con los máximos ajustes", para que cualquiera que tenga acceso a esta función tenga las máximas posibilidades. Esto, como muestra mi experiencia, es el camino equivocado. El camino correcto es, por el contrario, limitar al máximo al usuario, si un bloque del programa necesita la funcionalidad de otro bloque - debe tener sólo esta funcionalidad, y ni un poco más. Esta es la clave para un código más estable y libre de errores.
1. Bueno, la clase CTradePosition es esencialmente una lista de órdenes abiertas. Los pedidos pueden ser diferentes, y para ellos es muy conveniente tener una interfaz, una clase base y clases reales.
¿Y qué hay de malo en mantener las órdenes en una matriz de estructuras, o en la forma en que se implementa en MT4?
¿Qué hay de malo en mantener las órdenes en una matriz de estructuras o como se implementa en MT4?
Porque cada usuario tiene demasiados derechos y demasiada información innecesaria al acceder a esta matriz.
Lo correcto, en mi opinión, es dar al usuario sólo la parte de la funcionalidad que necesita, simplemente utilizando una interfaz preacordada para acceder a los pedidos.
Que cada usuario tiene demasiados derechos y demasiada información innecesaria al acceder a esta matriz.
Lo correcto, en mi opinión, es dar al usuario sólo la parte de la funcionalidad que necesita, simplemente utilizando una interfaz preacordada para acceder a los pedidos.
Puedes crear tu propio tipo de datos para las órdenes, no hay necesidad de ninguna interfaz, objetos y otros artificios innecesarios, que crean errores e inestabilidades innecesarias.
Puede crear su propio tipo de datos para las órdenes, no hay necesidad de ninguna interfaz, objetos y otros artificios innecesarios, que crean errores e inestabilidades innecesarias.
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 MT4 apareció OOP - inmediatamente empecé a traducir todos mis desarrollos en una sola forma, basada en interfaces.
1. Mi práctica demuestra que, efectivamente, es necesario. Esto me ha llevado a comprender su falacia.
2. No lo recuerdo, y prefiero tener acceso al menor número posible de entidades en cada bloque de programa.
1. Nunca se explica para qué sirve y cuál es la falacia. Dado que se trata de un tipo de datos especial, puede configurar allí el acceso como desee. El ejemplo es claramente una elección desafortunada.
2. Evidentemente, es un pensamiento erróneo negar al programador el acceso a sus datos en su programa con el pretexto de que va a cometer un error allí, ya que tendrá que crear todo tipo de intrincadas soluciones para permitir el acceso del programador y crear un código inestable con un montón de posibles errores en el camino. Es como prohibir al conductor que toque el volante y luego inventar soluciones-interfaces para que pueda dirigir el coche en lugar del volante.
2. Prohibir a un programador el acceso a sus datos en su programa bajo el pretexto de que supuestamente metería la pata allí - es obviamente un pensamiento erróneo, porque entonces hay que crear todo tipo de sofisticadas soluciones para dar acceso al programador y en el camino se crea un código inestable con un montón de posibles errores. Es como prohibir al conductor que toque el volante y luego inventar soluciones-interfaces para que pueda dirigir el coche en lugar del volante.
No. En cualquier lugar del código - sólo lo que se necesita en ese lugar debe estar disponible - todo lo demás debe ser cortado, si es posible.
En su situación con el conductor, significa que es razonable prohibir al conductor que toque el volante mientras el coche está aparcado. Así que no intenta girar una rueda mientras el coche está aparcado; de hecho, en ese momento, los sensores de alineación de las ruedas, por ejemplo, pueden estar conectados a las mismas, y el hecho de que el conductor agarre la rueda provocará errores en el ajuste de esos ángulos.
La idea es que en un momento dado, sólo esté disponible la funcionalidad que el programa necesita en ese momento, y todo lo demás estaría cerrado. Hace tiempo que estoy convencido de que esta es la forma de cometer menos errores.
No. En cualquier lugar del código - sólo debe estar disponible lo que se necesita en ese lugar - todo lo demás debe ser recortado, si es posible.
La idea es que en cada momento sólo estén disponibles para el programa aquellas funciones que se necesiten en ese momento y todo el resto debe estar bloqueado. Hace tiempo que aprendí que esta es la forma de cometer menos errores.Molestarse constantemente con lo que hay que prohibir y lo que hay que permitir es, obviamente, un requisito muy ilógico, a no ser, por supuesto, que el programador esté borracho cuando escribe el código y no se controle que puede escribir un montón de código que no entiende. Creo que no ayudará a un programador borracho a evitar errores en el código, y la gente sobria no lo necesita en primer lugar.
Preocuparse constantemente por lo que hay que prohibir y lo que hay que permitir es, obviamente, una exigencia muy ilógica, a no ser, por supuesto, que el programador se siente a escribir código estando borracho y no tenga control sobre sí mismo de que puede escribir un montón de código que no entiende. Creo que no ayudará a un programador borracho a evitar errores en el código, y la gente sobria no lo necesita en primer lugar.
Se trata de una exigencia muy lógica a la que acuden muchas personas.
No lo necesitas - bueno... no utilices OOP.