¿Qué puede hacer el código OOP que no pueda hacer el código procedimental? - página 2
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
Programar GUIs fue lo que hice la mayor parte de mi tiempo como programador. No es posible codificar una GUI completa que necesite comunicarse en varias direcciones mediante if then else. Necesitarías tantas declaraciones que el código se volvería ilegible y al final demasiado lento, lo que resultaría en no alcanzar el objetivo. Es un hecho.
No voy a construir una GUI en lenguaje procedimental para demostrar que estás equivocado. Pero podría sin duda alguna.
Por cierto, también es fácil codificar código ilegible y mucho más lento en POO, y como sabes la biblioteca estándar Metaquotes es una buena prueba de ello.
...
Debido a la circunstancia de que una CPU no sabe nada de POO, se puede - por supuesto - codificar todo sin sólo usar punteros y matrices complejas. Pero eso es absurdo. También podría contratar a 10000 personas que dibujaran el contenido de mi pantalla en una película en tiempo casi real y lo emitieran secuencialmente mediante un proyector de luz en la pared. ¿Es esto también llegar a la meta?
¿Estás de acuerdo en que el sistema operativo Windows ofrece una buena interfaz gráfica de usuario? Que yo sepa está escrito en C. Lenguaje procedimental no OOP.
Te equivocas Dirk si crees que un programa complejo sólo puede construirse con POO. Más bien deberías explicar por qué es mejor codificar con POO.
Eh, vamos ;) En realidad no ;) Si algo nativo podría hacer el trabajo de alguna manera extraña, entonces sus punteros, pero hay restricciones en MQL. Si entonces, de lo contrario ... el código se convertiría en absurdo.
Dudo mucho que la POO sea una forma más corta de codificar.
¿Estás de acuerdo en que el sistema operativo Windows ofrece una buena interfaz gráfica de usuario? Que yo sepa está escrito en C. Lenguaje procedimental, no POO.
Te equivocas Dirk si piensas que un programa complejo sólo puede construirse con POO. Más bien deberías explicar por qué es mejor codificar con POO.
Yo codifiqué GUIs en Assembler, completamente. Pero en Assembler puedo trabajar con punteros, en C puedo trabajar con punteros y por supuesto lo básico de Windows no es OOP, pero hablamos de MQL que no soporta punteros void de forma nativa y por eso, no podrás codificar GUIs complejos con sólo if then else, al menos no con un resultado que pueda ser usado sin gran falta de rendimiento.
Y esta respuesta incluye ya la pregunta, por qué es mejor con POO - por lo que "mejor" es todavía el adjetivo equivocado. El método OOP implementa el uso de tales punteros pero sin forzarte a tratar con ellos. Internamente, la POO se realiza con arrays multidimensionales para los punteros de funciones y variables. Tratar de codificar cosas así es lo mismo que reinventar una rueda que nunca rodará tan suave como la que ya tienes delante.
Yo codifiqué GUIs en Assembler, completamente. Pero en Assembler puedo trabajar con punteros, en C puedo trabajar con punteros y por supuesto lo básico de Windows no es OOP, pero hablamos de MQL que no soporta punteros void de forma nativa y por eso, no podrás codificar GUIs complejas con sólo if then else, al menos no con un resultado que pueda ser usado sin gran falta de rendimiento.
Y esta respuesta incluye ya la pregunta, por qué es mejor con POO - por lo que "mejor" es todavía el adjetivo equivocado. El método OOP implementa el uso de tales punteros pero sin forzarte a tratar con ellos. Internamente, la POO se realiza con arrays multidimensionales para los punteros de funciones y variables. Tratar de codificar cosas así es lo mismo que reinventar una rueda que nunca rodará tan suave como la que ya tienes delante.
Es sólo mi preferencia personal debido a mi pequeña(!) experiencia!
1) No me gusta, por ejemplo, Java, ya que el 99% de las veces busco una función sin saber cómo se llama, si existe o no, y si tengo que codificarla yo mismo...
2) No me gusta C++ porque tengo que escribir más de lo que necesitaría para escribir un lenguaje tipo script como mq4 o incluso Perl.
3) No me gusta C++ porque entender el código de otra persona me hace saltar de un archivo a otro donde sólo encuentro funciones con 2,3 líneas lo que hace realmente difícil averiguar qué y cómo se calcula el s.th. Por supuesto que hay explicaciones como "calcular el tope" pero el procedimiento de cálculo también está dividido en varias funciones en diferentes archivos.
4) Estoy absolutamente bien con enum y arrays de variables enum. No necesito codificar objetos reales imaginados. Los GUIs podrían ser un problema diferente ya que consisten en muchas otras cosas que podrían ser codificadas como objetos para una manera fácil de reutilizarlos. ¿Pero cuántos objetos diferentes necesita un EA? ¿Uno para las posiciones? Si hubiera muchos "objetos" diferentes (GUI) podría ayudar - pero no los veo aquí.
5) Finalmente MQ5 sigue sin poder ejecutar su backtest en los ticks de los clientes:( <Editado por el moderador como off-topic : esto no tiene nada que ver con mql5 sino con MT5>
Realmente respeto a alguien que codifica en ensamblador, debes tener un buen conocimiento de cómo funciona el hardware en sí mismo, simplemente increíble, duro que nadie utiliza hoy en día
Ya no lo codifico, pero en el pasado lo hacía principalmente. En los chips Intel 80x86 era la única posibilidad de conseguir una ventaja real en cuanto a rendimiento visual. Y por supuesto, es un conocimiento básico que no quiero perder en absoluto, aunque ya no lo necesite en detalle, pero siempre sabes lo que pasa con tu código al final y sabes cómo usar esto como una ventaja en vista de la velocidad de ejecución.
Sí, los "buenos" tiempos ;) ... Pero una locura también, ni siquiera había variables, ni funciones reales, ni if then else, sólo registros, pilas, interrupciones y direcciones de memoria. Una locura :)
OOP es una herramienta para dividir el código en pequeñas partes reutilizables. Pero la mejor parte son las plantillas. Esta característica permite simplificar el código. El mejor ejemplo es la clase array. En Java tienes que crear una clase para el tipo. En C++ y Mql5 puedes tenerlo en una clase reduciendo el código redundante y evitando algunos problemas cuando mezclas primitivas y objetos.
PD: Sobre ASM, es de la vieja escuela. Lo utilicé cuando antes de los primeros compiladores de modo protector y era divertido sobrepasar las limitaciones. Los segmentos de 64K con selectores eran la pesadilla de los programadores de aquella época. Cada vez que escribías en el lugar equivocado tenías que reiniciar el ordenador :)