OOP vs. programación procedimental - página 25
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.Realizó algunas clases de inclusión basadas en el artículo. No entiendo por qué usar clases en lugar de hacer un archivo de inclusión con funciones invocables.
2.Tengo una pregunta, para mejorar la velocidad de optimización ¿es mejor dividir los archivos de inclusión en varios o poner todo en uno?
3. Tengo la sensación de que si llamo al indicador en un archivo de inclusión, en lugar de en un Asesor Experto, la velocidad de optimización es más rápida...
1.Realizó algunas clases de inclusión basadas en el artículo. No entiendo por qué usar clases en lugar de hacer un archivo de inclusión con funciones invocables.
2.Tengo una pregunta, para mejorar la velocidad de optimización ¿es mejor dividir los archivos de inclusión en varios o poner todo en uno?
3.Tengo la sensación de que si llamo al indicador en un archivo include, en lugar de en un EA, la velocidad de optimización es más rápida...?
1. Las clases serán necesarias cuando se requiera polimorfismo, es decir, llamadas de diferentes funciones con propósito similar. El ejemplo más sencillo es cuando un bloque recibe un puntero a una orden y necesitamos obtener su entrada. Teniendo en cuenta las órdenes reales e históricas, así como MT4 y MT5 - tenemos cuatro funciones diferentes para trabajar.
En el caso del enfoque procedimental - necesitamos tener un determinado interruptor que llame a la función necesaria dependiendo del tipo de orden. En el caso de OOP - sólo llamamos a la función para obtener el billete. La función necesaria se llamará automáticamente. Sin embargo, en el caso de la programación orientada a objetos (OOP), necesitamos el trabajo previo para definir la jerarquía de clases y funciones.
2. La optimización se realiza según el módulo ejecutable listo. Por lo tanto, no importa si el código fuente está dividido en archivos o si está metido en un gran archivo. La división en archivos es únicamente la elección del programador, según le convenga.
3. No hay absolutamente ninguna diferencia. Personalmente, nunca llamo a ningún indicador, prefiriendo calcular sus valores directamente dentro de un Asesor Experto.
1. Las clases serán necesarias cuando se requiera polimorfismo, es decir, llamar a diferentes funciones con un propósito similar. El ejemplo más sencillo - un bloque recibe un puntero a una orden, necesitamos obtener su entrada. Teniendo en cuenta las órdenes reales e históricas, así como MT4 y MT5 - tenemos cuatro funciones diferentes para trabajar.
En el caso del enfoque procedimental - necesitamos tener un determinado interruptor que llame a la función necesaria dependiendo del tipo de orden. En el caso de OOP - sólo llamamos a la función para obtener el billete. La función necesaria se llamará automáticamente. Sin embargo, en el caso de la programación orientada a objetos (OOP), necesitamos el trabajo previo para definir la jerarquía de clases y funciones.
2. La optimización se realiza según el módulo ejecutable listo. Por lo tanto, no importa si el código fuente está dividido en archivos o se ha reunido en un gran archivo. Dividirlo en archivos es una decisión del programador de hacerlo él mismo.
3. No hay ninguna diferencia en absoluto. Personalmente nunca llamo a ningún indicador, prefiriendo calcular sus valores directamente dentro de un Asesor Experto.
Ya veo. Gracias. Por supuesto, todo esto es muy útil porque podemos envolver un montón de código en archivos y clases y dejar sólo un par de líneas en el Asesor Experto.
Por separado, es más fácil comprobar los fragmentos de código en busca de errores, añadir algo nuevo, etc. El código se hace más fácil de entender, especialmente para µl5.
Lo único que no está claro es por qué tantos jardineros locales se han convertido en excavadores convencidos y hacen una fosa en su propia parcela bajo un árbol).
Deben haber decidido construir una casa en su parcela también. ¿Qué hay de malo en eso?
Sí, por supuesto, incluso muchos de los grandes canales de los que ahora disfruta la humanidad se cavan con una pala. Pero en aquel entonces, simplemente no había excavadoras. Entonces, ¿por qué cavar una fosa con una pala ahora que hay excavadoras?
Deben haber decidido construir una casa en su parcela también. ¿Qué hay de malo en eso?
Sí, por supuesto, incluso muchos de los grandes canales que la humanidad utiliza ahora fueron excavados con una pala. Pero en aquel entonces, simplemente no había excavadoras. Entonces, ¿por qué cavar una fosa con una pala ahora que hay excavadoras?
La cuestión es que lo que tú entiendes por "pala" no es en absoluto lo que yo entiendo por programación "procedimental". Podría decirse que no estoy hablando de eso en absoluto. Lo que digo es que los métodos de resolución de problemas que algunos utilizan aquí son muy débiles en sí mismos, así que ¿qué diferencia hay -excavadora o pala- si ambos no se utilizan eficazmente?
Es una cuestión de profesionalidad, y su ausencia no puede ser sustituida por una herramienta...
Y si tienes profesionalidad, puedes construir montañas con métodos procedimentales. Créeme.
La cuestión es que lo que tú entiendes por "shovelware" no es en absoluto lo que yo entiendo por programación "procedimental". Podría decirse que no estoy hablando de eso en absoluto. Lo que digo es que los métodos de resolución de problemas que algunos utilizan aquí son muy débiles en sí mismos, así que ¿qué diferencia hay -excavadora o pala- si ambos no se utilizan eficazmente?
Es una cuestión de profesionalidad, y su ausencia no puede ser sustituida por una herramienta...
Y si tienes profesionalidad, puedes construir montañas con métodos procedimentales. Créeme.
No estoy en desacuerdo, pero prefiero gastar mi energía en convertirme en un operador profesional de excavadoras que en un excavador profesional.
Y no sé a qué te refieres con programación "procedimental", pero sé que la POO es un desarrollo evolutivo de la programación procedimental.
1.Realizó algunas clases de inclusión basadas en el artículo. No entiendo por qué usar clases en lugar de hacer un archivo de inclusión con funciones invocables.
2.Tengo una pregunta, para mejorar la velocidad de optimización ¿es mejor dividir los archivos de inclusión en varios o poner todo en uno?
3. Tengo la sensación de que si llamo al indicador en un archivo de inclusión, en lugar de en un EA, la velocidad de optimización es más rápida...
El misterio está claro - es un artículo :-) hay código por el código y el volumen del artículo en sí... "no leas el periódico antes de comer" :-)
La cuestión es que lo que tú entiendes por "shovelware" no es en absoluto lo que yo entiendo por programación "procedimental". Podría decirse que no estoy hablando de eso en absoluto. Lo que digo es que los métodos de resolución de problemas que algunos utilizan aquí son muy débiles en sí mismos, así que ¿qué diferencia hay -excavadora o pala- si ambos no se utilizan eficazmente?
Es una cuestión de profesionalidad, y su ausencia no puede ser sustituida por una herramienta...
Y si tienes profesionalidad, puedes construir montañas con métodos procedimentales. Confía en mí.
En general, Peter, tengo la sensación de que miras tu fosa, cavada con una pala, y miras la del vecino, cavada con una excavadora. Comparas y ves que tu trinchera es más grande y tiene los bordes más planos. Y concluyes que es mejor cavar con una pala. ¿Te imaginas que aprendieras a cavar con una excavadora... y puedes igualar los bordes con una pala.
Y, en general, Peter, tengo la sensación de que miras tu fosa, cavada con una pala, y miras la de tu vecino, cavada con una excavadora. Comparas y ves que tu trinchera es más grande y tiene los bordes más planos. Y concluyes que es mejor cavar con una pala. ¿Te imaginas que aprendieras a cavar con una excavadora... ...y puedes igualar los bordes con una pala.
Nikolai, si comparas las herramientas, no estaba cavando con una pala en absoluto. Es una herramienta diferente, mucho más genial. Todavía no he pensado cómo llamarlo, pero es muy posible que no pueda seguir el ritmo de una excavadora. El futuro lo dirá...
En general, respeto una excavadora como herramienta, pero no tuve tiempo de estudiarla. Otra idea se impuso).
Nikolai, si comparas las herramientas, no estaba cavando con una pala en absoluto. Es una herramienta diferente, mucho más genial. Todavía no he pensado cómo llamarlo, pero es muy posible que tampoco pueda seguir el ritmo de una excavadora. El futuro lo dirá...
En general, respeto una excavadora como herramienta, pero no tuve tiempo de estudiarla. Otra idea se impuso).
Si es cierto que has creado algo más genial que la OOP, ¿automografiarás la tuya cuando te hagas famoso?