OOP vs. programación procedimental - 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
George Merts:
Erm... No entendí bien el punto.
El objetivo era separar el CT del terminal. El código debe compilar en ambas plataformas sin ningún cambio. La super tarea - para transferir todos los TS escritos a WealhtLab Developer escribiendo sólo clases de trabajo con el servidor de comercio.
//--------------------------------------------------
Pregunté sobre la tarea actual para comparar sus soluciones según varios criterios y llegar a una conclusión sobre la eficacia de cada una. Estás alejando la conversación de la parte práctica. Cuando se afirma la eficacia de la POO, hay que ser capaz de demostrarla en la práctica. Pero estoy dispuesto a intentar demostrar mi opinión.
Entonces, ¿cuál es el problema actual? Espero que lo recuerde)
Si utiliza punteros a funciones, puede prescindir de la POO. Pero si no usas punteros, debes entender que no puedes ponerte al día con la POO.
¿Supongo que no eres programador? Entonces recuerda dónde estabas 2017.07.05 14:55 GMT 00, con quién estabas hablando y sobre qué ))
Si utiliza punteros a funciones, puede prescindir de la POO. Pero si no usas punteros, debes entender que no puedes ponerte al día con la POO.
No. Hasta que no haya una tarea concreta que me demuestre que no puedo ponerme al día con la POO, no puedo entenderla. Desgraciadamente. Son sólo palabras.
Actualmente tengo 4 años de práctica en programación. Puedes multiplicarlos por 2, porque estoy programando un montón de horas cada día. Durante este tiempo, he resuelto innumerables tareas diferentes. Todavía no he utilizado la OOP. No puedo entender por qué lo necesito. En mi consulta, todas las tareas se resuelven sin ella nada menos, y a veces incluso con más eficacia.
No. Hasta que no haya una tarea concreta que me demuestre que no puedo ponerme al día con la POO, no puedo entenderla en absoluto. Desgraciadamente. Son sólo palabras.
Imagina un hipotético programa que cambie su algoritmo en función de parámetros externos, podría haber un enorme número de variantes. Es posible resolverlo sin OOP, pero qué tontos se verían esos interruptores de varios pisos. Además, está claro que el rendimiento disminuirá a medida que aumente el número de variantes. También está claro que la construcción durante la inicialización se produce en OOP y, además, durante el funcionamiento, no se producen bifurcaciones innecesarias, es decir, el aumento del número de variantes no disminuirá el rendimiento.
Una característica distintiva de la programación estructurada es la división de los programas en bloques de código,
que realizan una tarea específica. En este caso, los bloques de construcción son funciones
y módulos (que pueden ser trasladados a archivos separados).
Más moderna es la programación orientada a objetos (POO).
El concepto de OOP se refiere más a la organización de los datos. La POO facilita la vida de un programador.
Los conceptos clave de la POO son los objetos y las clases.
Las clases son estructuras en las que se añaden funciones. Y los objetos son variables estructuradas o instancias de clases
La programación estructurada es el primer paso. Al dominarlo, el programador obtiene una ventaja. La POO es el siguiente paso con la siguiente ventaja
Resolvamos un problema concreto y comparemos.
He aquí una tarea sencilla (sería necesario escribir mucho para explicarla en detalle).
Todo sucede en OnTick(). Supongamos que comprobamos alguna condición y abrimos una orden. La condición no es importante, supongamos que es algún máximo o mínimo.
El robot, naturalmente, se sitúa en algún gráfico y obtiene cotizaciones de este símbolo. Está claro que no sólo tenemos una función OnTick, sino también otras funciones: OnTrade, OnTimer, funciones personalizadas, etc.
Por lo tanto, todas las variables que se comparten deben ser declaradas fuera de estas funciones al principio del código. Por ejemplo, el nombre del símbolo, la demanda, la oferta, el diferencial, el número de dígitos de la cotización, etc. Habrá docenas de ellos.
Este robot operará con un solo símbolo, es decir, donde se encuentre. Supongamos que hay 20 de estos gráficos y que vamos a instalar el mismo robot en todos ellos para operar simultáneamente para los 20 pares.
Pero no se trata de un robot de comercio multidivisa, como han señalado algunos operadores del Mercado.
Aquí tenemos que convertirlo en un robot multidivisa. Es decir, lo ponemos en cualquier gráfico (sólo en 1 gráfico) y abre operaciones para 20 pares. Significa que lo lanzamos en el probador en modo solitario y operará en aquellos pares que estén en Market Watch.
Así es como se implementará sin OOP. ¿Transformará todas las variables comunes en matrices de 20 elementos?
¿Y qué pasa con las funciones que se llamarán simultáneamente para todos los pares?
No se puede prescindir de la OOP. :)
P.S. Quiero señalar, que no tengo la educación rusa, y en consecuencia escribió mucho, y no tenía tiempo para leer varias páginas.
Si utiliza punteros a funciones, puede prescindir de la POO. Si no usas punteros, debes darte cuenta de que no puedes ponerte al día con la POO.
No estoy de acuerdo. En su día escribí programas de televisión digital, el compilador era C++, pero se usaba dentro de C porque la memoria era escasa. Los punteros a funciones se utilizaban mucho, pero esto no es ni de lejos POO.
...
Así es como lo harás sin OOP.
...
La pregunta más relevante en este caso no es "cómo" sino "por qué". Por qué necesitaría codificar algo que ya está implementado en el terminal - sólo necesita abrir el número requerido de gráficos y adjuntarlos al EA. Además, es probable que los parámetros sean diferentes para distintos símbolos y plazos.
No estoy de acuerdo. Solía escribir programas para la televisión digital, el compilador era C++, pero se usaba en C porque la memoria era escasa. Los punteros a las funciones se utilizaron mucho, pero no es ni mucho menos POO.
No es muy conveniente, pero se puede hacer con punteros solo en cuanto a rendimiento.
Y la comodidad es un concepto relativo.
Imagina un hipotético programa que cambie su algoritmo en función de parámetros externos, podría haber un enorme número de variantes. Es posible resolverlo sin OOP, pero qué tontos se verían esos interruptores de varios pisos. Además, está claro que el rendimiento disminuirá a medida que aumente el número de variantes. También está claro que con OOP hay una construcción en la inicialización y luego no hay bifurcaciones innecesarias durante el trabajo; es decir, el aumento del número de variantes no disminuirá el rendimiento.