Récord en el mercado - página 31
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
Probablemente porque no trabajo para una empresa. Y me parece más fácil utilizar la programación procedimental que la OOP.
Ha habido mucho debate sobre esto, por supuesto.
Bueno, justo en la última semana he estado haciendo algunas modificaciones en el algoritmo de estimación de la calidad de las operaciones para mi Liga TS. Y estoy muy contento de que todo se base en interfaces virtuales.
La cuestión es que antes la detracción máxima se estimaba sólo por saldo. Y quería estimarlo por la Equidad. Pero para ello, al analizar el historial, es necesario solicitar la serie temporal de cada transacción, y ver cuál fue la reducción máxima de la transacción, en función de los precios de entonces.
Ahora recuerde, que mi código es portátil, significa que basado en la misma interfaz - tanto MT4 y MT5 trabajo. En consecuencia, para cada plataforma - llama a la clase apropiada con sus propias funciones, que son notablemente diferentes. Así que, mientras modificaba el código, probablemente una docena de veces me encontraba en una situación en la que no podía acceder directamente a los datos requeridos, ya que las interfaces no lo permitían. Y cada vez me aseguraba de que estaba en lo cierto, de que las interfaces me habían limitado -si hubiera "trasteado" con esos datos directamente- habría provocado errores en otras partes del programa. Tuve que acceder a los datos que necesitaba de una manera diferente, mediante consultas adicionales, lo que me permitió estar seguro de que ninguna otra parte se veía afectada.
En resumen: una vez más estoy convencido de que el principio "en cada lugar el usuario debe tener acceso sólo a las estructuras que necesita en ese momento y no a otras" es absolutamente correcto. No se puede permitir que el usuario tenga siempre acceso a todo: está plagado de errores de modificación.
Pero, por otro lado, las personas que están acostumbradas a un estilo procedimental, simplemente se limitan en estos casos a recordar qué datos se pueden modificar desde un lugar determinado y cuáles no.
Bueno, justo en la última semana he estado haciendo algunas modificaciones en el algoritmo de evaluación de la calidad de las operaciones para mi Liga TS. Y me alegro mucho de que todo se base en interfaces virtuales.
La cuestión es que antes la detracción máxima se estimaba sólo por saldo. Y quería estimarlo por la Equidad. Pero para ello, al analizar el historial, es necesario solicitar la serie temporal de cada transacción, y ver cuál fue la reducción máxima de la transacción, en función de los precios de entonces.
Ahora recuerde, que mi código es portátil, significa que basado en la misma interfaz - tanto MT4 y MT5 trabajo. En consecuencia, para cada plataforma - llama a la clase apropiada con sus propias funciones, que son notablemente diferentes. Así que, mientras modificaba el código, probablemente una docena de veces me encontraba en una situación en la que no podía acceder directamente a los datos requeridos, ya que las interfaces no lo permitían. Y cada vez me cercioraba de que estaba en lo cierto, de que las interfaces me habían limitado -si hubiera "pinchado" en estos datos directamente- habría provocado errores en otras partes del programa. Tuve que acceder a los datos que necesitaba de otra manera, mediante consultas adicionales, lo que me permitió estar seguro de que ninguna otra parte se veía afectada.
En resumen: una vez más estoy convencido de que el principio "en cada lugar el usuario debe tener acceso sólo a las estructuras que necesita en ese momento y no a otras" es absolutamente correcto. No hay que dejar que el usuario tenga siempre acceso a todo lo que necesita, ya que podría provocar errores de modificación.
Pero, por otro lado - las personas acostumbradas al estilo procedimental - se limitan en estos casos a recordar qué datos pueden y no pueden ser modificados desde el lugar dado.
Bueno, esa es la competencia. No se puede evitar. No te rindas, sigue avanzando y gana. De lo contrario, te quedarás atrás.
Olvídate de la OLP. Si esta pregunta le molesta, puedo decirle que en la programación debe utilizar sólo lo que puede prescindir. Si se puede hacer con estilo procedimental, hágalo.
Mi principio:"Si puedes prescindir de algo para resolver una tarea, definitivamente debes prescindir de ello".
¿Necesita el perro una quinta pata? :)
Exactamente.
Ese es el tipo de competencia que necesitas.
Te sorprendería, pero todavía sufro de programación procedimental.
Me metí en Pascal cuando tenía 14 años y no puedo cambiarme. Y yo "aprendí las clases" hace mucho tiempo, pero no puedo cambiar de opinión...
Probablemente porque no trabajo para una empresa. Y me parece más fácil utilizar la programación procedimental que la OOP.
Los principios de la POO no difieren mucho de la programación procedimental, más aún en los programas MQL las tareas son altamente especializadas y a menudo no tiene sentido desarrollar la estructura interna de una clase. Más del 90% de los ejemplos que utilizan clases en Codobase no son más que programación procedimental "envuelta en clase", porque las tareas que se resuelven con una clase se realizan una sola vez y no se utiliza la herencia ni el polimorfismo (porque no es necesario).
Y los problemas graves, en los que no hay manera sin la POO - es un gráfico. Este problema ya ha sido resuelto y está en el libre acceso y sólo hay que saber utilizarlo o modificarlo (como la herencia).
Ya lo han hecho y está disponible de forma gratuita, sólo es cuestión de saber cómo utilizarlo (gráficos en MQL) o cómo modificarlo (para utilizar la herencia).
¡ZZZY: eso es lo que no voy a decir sobre la usabilidad en términos de ALGLIB - ciertamente debería ser "envuelto" en una clase normal!
Igor Makanu:
...
Y las tareas serias en las que no se puede prescindir de la POO son los gráficos...
Muy controvertido)).
Muy controvertido)).
Los principios de la POO no difieren mucho de la programación procedimental, especialmente en los programas MQL las tareas son muy especializadas y a menudo no tiene sentido desarrollar la estructura interna de una clase. Más del 90% de los ejemplos que utilizan clases en Codobase no son más que programación procedimental "envuelta en clase", porque las tareas que se resuelven con una clase se realizan una sola vez y no se utiliza la herencia ni el polimorfismo (porque no es necesario).
Y los problemas graves, en los que no hay manera sin la POO - es un gráfico. Este problema ya ha sido resuelto y está en el libre acceso y sólo hay que saber utilizarlo o modificarlo (como la herencia).
Ya lo han hecho y es de libre acceso, sólo es cuestión de saber cómo utilizarlo (gráficos en MQL) o cómo heredarlo (cómo utilizar la herencia).
¡ZZZY: eso es lo que no voy a decir sobre la usabilidad en términos de ALGLIB - ciertamente debería ser "envuelto" en una clase normal!
Depende para qué.
¿Para facilitar el uso por parte de otros usuarios?
Posiblemente, sí.
Para que los usuarios no tengan ganas de "enredar" y causar algún daño.
Utilizo 5 funciones de dibujo para mis gráficos (texto, botón, casilla, campo, fondo) !)
Todo está claro para mí. Los demás no necesitan verlo.
Exactamente.
Ese es el tipo de competencia que necesitamos.
Sueño con que esa competencia crezca en nuestro Mercado. Sólo hay que limpiar el mercado.
Para que el baño sea perfecto, primero hay que limpiar la piscina y luego llenarla de agua. En resumen, se necesitan las condiciones adecuadas.
Si la piscina está sucia, nadie querrá competir. :)Bueno, justo en la última semana he estado haciendo algunas modificaciones en el algoritmo de evaluación de la calidad de las operaciones para mi Liga TS. Y me alegro mucho de que todo se base en interfaces virtuales.
La cuestión es que antes la detracción máxima se estimaba sólo por saldo. Y quería estimarlo por la Equidad. Pero para ello, al analizar el historial, es necesario solicitar la serie temporal de cada transacción, y ver cuál fue la reducción máxima de la transacción, en función de los precios de entonces.
Ahora recuerde, que mi código es portátil, significa que basado en la misma interfaz - tanto MT4 y MT5 trabajo. En consecuencia, para cada plataforma - llama a la clase apropiada con sus propias funciones, que son notablemente diferentes. Así que, mientras modificaba el código, probablemente una docena de veces me encontraba en una situación en la que no podía acceder directamente a los datos requeridos, ya que las interfaces no lo permitían. Y cada vez me cercioraba de que estaba en lo cierto, de que las interfaces me habían limitado -si hubiera "pinchado" en estos datos directamente- habría provocado errores en otras partes del programa. Tuve que acceder a los datos que necesitaba de otra manera, mediante consultas adicionales, lo que me permitió estar seguro de que ninguna otra parte se veía afectada.
En resumen: una vez más estoy convencido de que el principio "en cada lugar el usuario debe tener acceso sólo a las estructuras que necesita en ese momento y no a otras" es absolutamente correcto. No hay que dejar que el usuario tenga siempre acceso a todo lo que necesita, ya que puede provocar errores de modificación.
Pero, por otro lado, las personas que están acostumbradas a un estilo procedimental, simplemente se limitan en estos casos a recordar qué datos se pueden cambiar desde un lugar determinado y cuáles no.
Con todo el respeto, pero tus argumentos son como los de un hombre muy viejo que explica y demuestra la necesidad del palo en el que se apoya. Dicen que sin ella seguramente me caeré. Es cierto. Pero no para todos.
Muy controvertido)).
Puede ser, pero yo también soy un "dinosaurio de finales de los 90" vi Turbo Pascal y los rudimentos de los gráficos en forma de librerías de las que no importa cómo lo hilvanes - sigues obteniendo Norton Commander ))))
Pero con la llegada (y mi transición) a Delphi, como se dice, ahí empezó la vida.... No me imagino cómo hacer ventanas activas, casillas de verificación, etc. sin POO, supongo que en teoría, pero ni siquiera veo cómo se puede hacer sin POO, ¡como dicen que uno se acostumbra a lo bueno!
Con todo el respeto, tus argumentos son como los de un hombre muy mayor que explica y demuestra la necesidad del palo en el que se apoya. Sin ella, estoy destinado a caer. Es cierto. Pero no para todos.
Usted, según recuerdo, recuerda perfectamente todo lo que hay en su enorme conjunto de datos. Yo, en cambio, no recordaba esas cosas ni siquiera cuando era joven. Ahora, cuando sea un anciano, seguramente no podré recordar todo lo que quise decir cuando escribí un determinado bloque. Este "palo" me ayuda mucho. Pero, estoy de acuerdo en que si alguien es capaz de retener todo lo necesario en su memoria, puede prescindir de ella.
Sin embargo, ya he citado varias veces el código respetado de fxsaber, donde él mismo no pudo decirme exactamente cómo funciona. Lo que ocurre es que tiene comprobaciones muy complicadas y poco evidentes que, efectivamente, son difíciles de recordar. Y el hombre no lo recuerda. El consenso era que "este código ha sido comprobado muchas veces, por lo que se puede confiar en él". Pero, ¿qué pasará si cambian algunos protocolos de trabajo? El código se convierte inmediatamente en inválido, y en este caso -en lugar de corregir lo que ha cambiado- habrá que volver a examinarlo hasta encontrar ese mismo lugar cambiado.
Para eso están estos "palos". Los productos de software de hoy en día son tan complicados que no es realista tener en cuenta todos sus entresijos. Por eso se utilizan diversas técnicas (la POO es sólo una de ellas).