OOP vs. programación procedimental - página 35
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
Cuidado, no estamos hablando de variables internas de la MT, estamos hablando de variables internas del objeto que has aislado, impidiendo la posibilidad de leer sus valores mientras depuras y escribes código...
Eso es lo que estoy diciendo - cuando depuras un EA - ¿no necesitas las variables internas de MT?
Del mismo modo, en este caso, con el objeto procesador de operaciones - si está depurando, digamos, la metodología de colocación de órdenes en su ST - ¿por qué tendría acceso a las variables internas del procesador de operaciones?
Andrei es aún más clínico que Peter o Sansanych, estás perdiendo el tiempo.
Hay que enseñar a los jóvenes.
Además, tal vez haya una razón racional en lo que dicen mis oponentes. Si yo tuviera, por ejemplo, una memoria como la de Peter, quizá no me molestaría también con la OLP.
Lo mismo ocurre en otros lugares: si se necesita algún dato, este bloque tiene que proporcionar la interfaz adecuada.
A eso me refiero... En lugar de limitarse a ver el valor de la variable requerida, hay que pensar en cómo engancharle una interfaz adecuada y luego desengancharla. :)
Parece una actividad para masoquistas de la programación :)
Sí... no puedes evitar preguntarte qué contiene :) La idea es tener un lenguaje de programación adecuado, para facilitar la depuración y la escritura de código con los mínimos gestos, pero aquí tenemos una situación completamente opuesta...
No se trata de una "situación opuesta". Es cierto que la POO requiere algo de trabajo extra. Sin embargo, se compensa con creces por la comodidad del soporte y la modificación del sistema.
También en este caso -volviendo al procesador de comercio- se escribe y se utiliza en muchos ST. Es el aislamiento de sus internos del ST, y trabajar sólo a través de una interfaz virtual permite no pensar en qué variables están en él y a qué son iguales. Si se detectan errores, estarán dentro del procesador y habrá que arreglarlos dentro de una clase real, no afectando a las clases TS. Si el error está en el propio ST, no afectará a las variables del procesador de comercio.
La encapsulación es en realidad una técnica muy útil.
Sí... no puedes evitar preguntarte qué demonios contiene :) La idea es tener un lenguaje de programación adecuado, para facilitar la depuración y la escritura de código con los mínimos gestos, pero aquí tenemos una situación completamente opuesta...
La depuración se facilita precisamente por la división de responsabilidades en cada clase: cada clase es responsable de su propio conjunto de variables. Ninguna otra clase tiene derecho a cambiar sus valores. De este modo, la mayoría de los problemas se eliminan ya en la fase de compilación. Y el acceso a las variables desde cualquier lugar del programa puede compararse con una docena de volantes en un barco.
Hay que enseñar a los jóvenes.
Además, tal vez haya una base racional en lo que dicen mis oponentes. Si yo tuviera, por ejemplo, una memoria como la de Pedro, tampoco me molestaría en la OOP.
1. ¿En qué medida ha aumentado la rentabilidad de sus asesores gracias al uso de las OOP?
2. ¿En qué medida ha disminuido la rentabilidad de sus asesores por el uso de OOP?
Eso es lo que quiero decir... En lugar de limitarse a ver el valor de la variable requerida, hay que pensar en cómo engancharle una interfaz adecuada y luego desengancharla. :)
Parece una actividad para masoquistas de la programación :)
Verás, arriba en el tema, Pedro te mostró una de sus estructuras, no la más grande.
¿Puedes descubrirlo fácilmente?
Este mismo "masoquismo" es el que le permite, en primer lugar, no entrar en el código de trabajo y no estropearlo. Y en segundo lugar, le permite diseñar inmediatamente la estructura del sistema para que pueda proporcionar los datos necesarios en los bloques correspondientes del programa.
Sí, efectivamente, hay situaciones en las que de repente te das cuenta de que es casi imposible conseguir los datos necesarios. Se esconden detrás de varias interfaces virtuales. Sin embargo, esta situación muestra claramente que el sistema fue diseñado originalmente de forma incorrecta, no preveía la transmisión de estos datos. Esta situación es muy desagradable. O bien tenemos que construir apresuradamente "muletas" en forma de interfaces adicionales, o bien reestructurar todo el sistema. Bueno... Esto motiva al programador a pensar más cuidadosamente en la arquitectura del sistema.
Si tuvieras menos emoción y reflexividad y más especificidad en la esencia de la discusión, no valdrías. :)
Esta discusión ya no tiene sustancia. Fundamentalmente, estás floreciendo y haciéndote el obtuso.
Si un moderador cierra el último par de páginas por considerarlas irrelevantes para el tema del hilo y la programación en general, será un caso raro en el que apoyaré sus acciones.
1. ¿En qué medida ha aumentado la rentabilidad de sus EAs al utilizar OOPs?
2. ¿En qué medida ha disminuido el índice de fracaso de sus asesores gracias al uso de la OOP?
1. No por cuánto. La rentabilidad no depende de la OOP.
2. En mi opinión, por un orden de magnitud (diez veces). Pero la principal ganancia de la POO está en el soporte del código. Ahora soy muy rápido en descifrar el código que escribí hace un año o más. Recuerdo bien cómo entendía mis primeros programas ANSI C en estilo puramente procedimental. Era mucho más difícil.
La depuración se facilita precisamente por la división de responsabilidades en cada clase: cada clase es responsable de su propio conjunto de variables. Ninguna otra clase tiene derecho a cambiar sus valores. De este modo, la mayoría de los problemas se eliminan ya en la fase de compilación. Y el acceso a las variables desde cualquier punto del programa puede compararse con una docena de volantes en un barco.
No puedo entender porque NUNCA me he encontrado con algo así en mi trabajo. ¿Por qué los problemas de diferenciación de acceso a las variables por parte de UN desarrollador en un programa no muy grande? Habría 100 desarrolladores, cada uno escribiendo 100 funciones. En teoría, se podría inventar. Pero prácticamente, la programación ha evolucionado hacia la POO desde hace casi 40 años, se han escrito montañas de código y nunca se ha oído nada parecido.