Gastos generales de la OLP - página 2
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
Por supuesto, la hermosa OOP debe pagarse con recursos y mucho tiempo de depuración. La POO sólo tiene sentido como un práctico envoltorio de texto o con un uso mínimo en la inicialización en tiempo de ejecución... En realidad, la POO no era más que una cosa de marketing de Microsoft para aumentar los costes de las horas de trabajo de los programadores y estimular la compra de equipos más avanzados. Y ellos mismos no son tontos y escriben todo el software en C y ensamblador.
qué montón de mierda.
todo el mundo sabe que los programadores de MS escriben directamente en código máquina
cada programador tiene un libro con los códigos de las máquinas procesadoras en su escritorio y simplemente graban los códigos en tarjetas perforadas
Bill Gates puede compilar un sistema operativo en su cabeza).
Menuda chorrada.
Todo el mundo sabe que los programadores de MS escriben directamente en código máquina
Tu payasada no es del todo clara, se sabe que las inserciones en lenguaje ensamblador se utilizan para mejorar el rendimiento del código...
Puedo suponer que la POO se utiliza en terminal al mínimo o no se utiliza porque es difícil conseguir archivos tan compactos sin grandes bibliotecas externas como en dotnet...
¿Tienes algún argumento significativo sobre la esencia de lo que se dijo?
Compruébalo. En efecto, Alexei está reaccionando emocionalmente. Y en esencia, las objeciones son las siguientes.
La programación orientada a objetos es muy útil cuando se necesita soportar algún código complejo.
Ciertamente, no tiene sentido aplicar todos los trucos OOP a un indicador-MA. Aunque cuando se escriben clases básicas - incluso para MA - todavía el enfoque OOP es al menos tan bueno como un enfoque habitual, procedimental.
La principal ventaja de la POO se revela con el apoyo de las estructuras de objetos desarrolladas. Cuando la encapsulación asegura la ausencia de la necesidad de entender todos los matices de las funciones sobrecargadas cada vez. Cuando se basa en el polimorfismo, lareutilización del código es mucho mayor.
La esencia de la OOP se acerca más al mundo real, donde cualquier objeto está siempre relacionado con sus propiedades y tiene ciertas reglas de interacción con el entorno.
Sobre el "aumento del coste de las horas de trabajo" - no es así. Ciertamente, cuando se diseña un sistema en el estilo OOP se requiere un poco más de trabajo que en el enfoque orientado a los procedimientos. Sin embargo, estos costes adicionales se ven compensados con creces por la comodidad de mantener y modificar el código escrito.
Personalmente, escribo indicadores muy pequeños "con la rodilla" sin ningún objeto. Sin embargo, cuando se requiere algo más (al menos multiplataforma), siempre utilizo el estilo OOP y las prácticas existentes en las bibliotecas de objetos.
Tu payasada no está del todo clara, sabemos que las inserciones en lenguaje ensamblador se utilizan para mejorar el rendimiento del código...
Puedo suponer que el terminal utiliza un mínimo o ningún OOP, porque sin enormes bibliotecas externas como en dotnet es difícil conseguir archivos tan compactos...
1. OOP - ayuda mucho cuando se necesita soportar algún tipo de código complejo.
2. por supuesto, no tiene sentido aplicar todos los trucos OOP para el indicador-MA. Aunque, cuando se escriben clases básicas - incluso para MA - todavía el enfoque OOP es al menos tan bueno como un enfoque habitual, procedimental.
3. La principal ventaja de la POO se revela con el apoyo de las estructuras de objetos desarrolladas.
1. ¿Por ejemplo? Los eslóganes pegadizos son buenos, pero no está claro qué significan exactamente...
2. Ya se ha dicho que como envoltura de texto la POO es buena, pero eso es porque no se ha puesto al día en la programación procedimental.
3. ¿Por qué necesitamos multiplicar estas "estructuras desarrolladas"? Será destructivo para el rendimiento del código y no es seguro que sea más fácil y rápido detectar errores en él.
Los compiladores modernos optimizan muchas veces mejor que un programador medio o incluso bueno.
Tal vez algunas cosas simples y triviales pueden, pero sólo porque la gente se sentó y escribió manualmente el algoritmo, pero si algo no estándar, está lejos de ser seguro, especialmente si las características OOPesheh se encuentran allí.
En los controladores, sí, usan assebler, pero no por la velocidad, simplemente es más fácil trabajar con el hardware..,
Bueno, la gente no es estúpida, ¿por qué querría algo complicado y confuso que además es lento?
¿Y por ejemplo? Los eslóganes pegadizos están bien, pero es difícil entender de qué estamos hablando exactamente... 3.
2. Ya se ha dicho que como envoltura de texto la POO es buena, pero eso es porque no se ha llevado a cabo en la programación procedimental.
3) ¿Por qué debemos multiplicar estas "estructuras desarrolladas"? Sería terrible para el rendimiento del código y no es el hecho de que será más fácil y más rápido para detectar errores en él.
1. Por ejemplo, necesitas un array de objetos. Esto bien podría hacerse de forma procedimental o basándose en CArrayObj y CObjest. Los problemas comenzarán cuando se necesite cambiar el comportamiento de, por ejemplo, añadir o eliminar objetos u ordenarlos. En la programación orientada a objetos (OOP), el soporte para una matriz de punteros propiamente dicha y el trabajo con ella se incluye 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á más fácilmente a errores.
Multiplataforma - también es mucho más conveniente organizar en estilo OOP. Cuando al solicitar, digamos, una posición comercial - obtenemos una interfaz, y no importa en qué plataforma trabajemos - la interfaz ofrece funciones virtuales, en las que podemos obtener todos los datos sobre todas las órdenes (para MT4) o posiciones (MT5), y, desde el punto de vista del experto - no hay ninguna diferencia. El Asesor Experto no necesita saber en qué plataforma trabaja.
2. Pues bien, "terminar en la programación procedimental" significa "escribir objetos-procedimientos", es decir, la creación de algunos vínculos entre los datos y los procedimientos, que representan objetos en la POO.
3. 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 descendientes representarían diferentes tipos de órdenes. En este caso, el procesador de operaciones (tengo la clase CTradeProcessor) apoyará automáticamente exactamente esa orden, que se le ha pasado, por aquellos procedimientos que sean necesarios para procesar esta orden.
Es más fácil detectar los errores cuando hay menos enlaces cruzados. Que es exactamente lo que proporcionan 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, y esto precisamente 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.