Una pregunta para los expertos en POO. - página 11
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
Si un programador se adentra en el mundo del forex, no es necesario que sea un profesional y que conozca la POO.
Es mejor aprender los entresijos del mercado y desarrollar una estrategia de negociación rentable. Y no importa si se utiliza OOP o no. La rentabilidad del Asesor Experto no se verá afectada por ello.
No tienes que desperdiciar tu energía.
George, no se trata sólo de la memoria. He creado un entorno de desarrollo cómodo para mí, utilizando mi lengua materna y también el inglés. El código bilingüe se recuerda MUCHO mejor que el monolingüe. Especialmente cuando no te quedas con las palabras estándar y llamas a las variables por el nombre que quieras. Probado. Simplemente ignoré la profesionalidad en la programación y empecé a escribir a mi antojo. Como resultado, empecé a navegar rápidamente por mi código y a leerlo, recordarlo y desarrollarlo con facilidad. El resto ya lo conoces...
No creo que pueda ayudar. Para mí los nombres de las variables en cualquier lenguaje se borran de mi memoria casi al instante, me levanto de detrás del ordenador y ya sólo recuerdo los principios generales y no puedo saber qué variables se han introducido en cada lugar.
Por cierto, esa es la razón por la que siempre uso pares de archivos mqh-mq5 en lugar de escribir las clases enteramente en archivos mqh - necesito mirar los archivos de cabecera a menudo, sólo para recordarme lo que está disponible en uno u otro caso, tengo los archivos mqh de cabecera necesarios abiertos en pestañas, y cambio a ellos cuando necesito refrescar esa información de nuevo. Cuando toda la clase (y aún más varias clases) se describen en un archivo mqh, es más difícil "saltar" a través de este archivo, incluso con la ayuda de pestañas.
No puedo mantener toda la estructura en la memoria, aunque en mi juventud, como ya he mencionado, llegué a escribir en ensamblador, pero no hay otras opciones - sólo tienes direcciones de memoria, y lo máximo que permite el ensamblador de macros es crear nombres de áreas específicas usando macrosubstituciones. Esto también funciona. Pero hace tiempo que me convencí de que de esta manera el número de errores es mucho mayor y la depuración de dicho código es mucho más difícil.
Ya di un ejemplo más arriba: se produce un error y una variable se modifica incorrectamente por alguna razón. Y se accede a la variable desde muchos lugares del programa. ¿Cómo atrapar un lugar donde hay un error? Con la encapsulación OOP es muy simple - ponemos un punto de interrupción en la función de la interfaz que modifica la variable, y tan pronto como se produce una modificación incorrecta - nos detenemos e inmediatamente, por la jerarquía de llamadas, vemos donde se hizo la modificación incorrecta.Y con tu enfoque, Peter, tenemos que escarbar en todo el código, buscando en todos los lugares donde se accede a esta variable, poniendo puntos de interrupción en todas partes, y analizando todas las llamadas, no sólo las incorrectas.
Esa es la cuestión, puede sufrir. El amigo mío perdió una parte de su depósito por un error en su código, mientras que la POO hace que los errores sean menos probables.
Significa que no es un buen programador. Puedes confundirte más en construcciones OOP complejas que sin ellas.
Las clases deben aplicarse cuando sea necesario. Me he dado cuenta de que algunos programadores tienen la obsesión de aplicar muchas funciones donde no son necesarias. Ocurre lo mismo con las clases.
En lugar de escribir un programa compacto y corto sin POO, algunos programadores empiezan a aplicar clases, muchas funciones y una solución sencilla se convierte en un texto kilométrico.
Eso significa que no es un buen programador. Puedes confundirte más en construcciones OOP complejas que sin ellas.
¿Si todo lo demás es igual? Lo dudo mucho. Si la complejidad de las construcciones es la misma, es mucho más fácil darles sentido con la POO.
Sin embargo, no anula la regla "con un cañón sobre un gorrión", no tiene sentido utilizar grandes complejidades OOP donde la tarea es muy simple y compacta.
Aunque, como ya se dijo aquí, la POO nos permite construir bibliotecas de clases, que luego se utilizan en muchos proyectos.
Digamos que las mismas clases de matriz, clases de archivo... Incluso cuando se escribe un indicador muy simple, sin utilizar la POO, es mucho más fácil declarar una clase CFile y utilizar sus funciones, en lugar de utilizar las funciones estándar de trabajo con archivos.Por no hablar de la posibilidad de sustituir fácilmente CFile con otros más específicos, por ejemplo, tengo una clase CLogFile con capacidad para insertar automáticamente la hora y algunos datos adicionales en las cadenas (para los archivos de registro) o la clase CIniFile, que puede organizar los datos en archivos ini estándar, y luego leerlos y utilizarlos cuando sea necesario.
Significa que no es un buen programador. Puedes confundirte más en construcciones OOP complejas que sin ellas.
Las clases deben aplicarse cuando sea necesario. Me he dado cuenta de que algunos programadores tienen la obsesión de aplicar muchas funciones donde no son necesarias. Ocurre lo mismo con las clases.
En lugar de escribir un programa compacto y corto sin POO, algunos programadores empiezan a aplicar clases, muchas funciones y una solución sencilla se convierte en un texto kilométrico.
¿Está bien que el trabajo real sea un centenar de líneas, y el par de miles restantes sea una biblioteca escrita y depurada hace tiempo? )))
Si un programador utiliza en su programa clases ya hechas, como estas: CTrade, CAccountInfo, CPositionInfo, no significa que su programa esté basado en la POO.
Depende de si el programador crea esas clases él mismo, o simplemente las utiliza sin conocer las interioridades (a nivel de texto fuente) de esas clases.
....
Ya se ha dado un ejemplo más arriba: se ha producido un error, por alguna razón se ha modificado incorrectamente una variable. Y se accede a la variable desde un montón de lugares en el programa. ¿Cómo atrapar un lugar donde el error? Con la encapsulación OOP es muy simple - ponemos un punto de interrupción en la función de la interfaz que modifica la variable, y tan pronto como se produce una modificación incorrecta - nos detenemos e inmediatamente, por la jerarquía de llamadas, vemos donde se hizo la modificación incorrecta.Y con tu enfoque, Peter, tenemos que escarbar en todo el código, buscando en todos los lugares donde se accede a esta variable, poniendo puntos de interrupción en todas partes, y analizando todas las llamadas, no sólo las incorrectas.
Sí, mi núcleo se modifica en todas las partes del programa y se producen errores, pero no necesito puntos de interrupción. Calculo en mi mente y alerto en varios lugares para comprobar los valores. Así es como lo encuentro. Insisto: conozco muy bien mi programa.
Pero, en el lado positivo, con estos conocimientos, sin obstáculos sintácticos y con una lengua nativa, tengo enormes oportunidades de desarrollo rápido. Y por eso estoy en contra de la OOP en mis soluciones.
La división del código, su monolingüismo ajeno, la nueva sintaxis, las reglas adicionales... todo ello ralentizará el desarrollo del programa. Perderé más esfuerzo y obtendré menos resultados. Lo sé con certeza.
Si mi tarea fuera construir y depurar un programa a partir de trozos de código ya hechos, sólo servirían la POO y las bibliotecas. Enganchar y desarrollar nuevas soluciones son cosas diferentes. Mucha gente aboga por la POO porque quiere utilizar trozos de código de otras personas y ahorrar esfuerzo. Creo mis propias soluciones utilizando tecnología propia y tengo diferentes necesidades y puntos de vista sobre la POO.
Sí, mi núcleo se modifica en todas las partes del programa y se producen errores, pero no necesito puntos de interrupción. Calculo en mi mente y alerto en varios lugares para comprobar los valores. Así es como lo encuentro. Insisto: conozco muy bien mi programa.
Pero el lado positivo es que con esos conocimientos, la ausencia de obstáculos sintácticos y la lengua materna, tengo enormes oportunidades de desarrollo rápido. Y por eso estoy en contra de la OOP en mis soluciones.
La división del código, su monolingüismo ajeno, la nueva sintaxis, las reglas adicionales... todo ello ralentizará el desarrollo del programa. Perderé más esfuerzo y obtendré menos resultados. Lo sé con certeza.
Si mi tarea fuera construir y depurar un programa a partir de trozos de código ya hechos, sólo servirían la POO y las bibliotecas. Enganchar y desarrollar nuevas soluciones son cosas diferentes. Mucha gente aboga por la POO porque quiere utilizar trozos de código de otras personas y ahorrar esfuerzo. Creo mis propias soluciones utilizando tecnología propia y tengo diferentes necesidades y puntos de vista sobre la POO.
Aconsejo utilizar la plantilla de cuadros de diálogo de VC++ al menos una vez, crear una aplicación basada en el CDialog de MFC, establecer todo tipo de controles en él en modo visual, utilizar las funciones ya hechas para entender todo el poder de la POO.
Y también me gustaría añadir que Borland C++ tiene clases muy útiles para trabajar con Oracle. Trabajé con él hasta 2012, ahora no sé cómo.
Aconsejo utilizar la plantilla de cuadros de diálogo de VC++ al menos una vez, crear una aplicación basada en el CDialog de MFC, establecer todo tipo de controles en él en modo visual, utilizar funciones ya hechas, para entender todo el poder de la POO.
Y también me gustaría añadir que Borland C++ tiene clases muy útiles para trabajar con Oracle. Trabajé con él hasta 2012, ahora no sé cómo.
es la segunda mitad de 2019.... pero tanto el 20 como el 25 y .... ¿También discutirá sobre la necesidad de utilizar la POO?
))))
si nos gusta, lo usamos, si no nos gusta, no lo usamos.
si te acostumbraste a escribir programas utilizando pequeñas subrutinas previamente escritas - escribe, te levantaste con el pie izquierdo... pones todas estas subrutinas en el código fuente y obtienes un gran lío de código
dar a la gente un montón de posibilidades del código abierto, todavía no es lo mismo, recortar la funcionalidad a C puro, de nuevo no es lo mismo ))))
ZS: Sospecho que algunos de los desarrolladores están leyendo el foro de todos modos... Creo que este hilo les animará definitivamente. ))))