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
los modificadores de derechos de acceso permiten detectar errores en tiempo de compilación
En general, todo esto no complica el trabajo con las clases, no lo use, escribir todo en público: y entonces será más fácil trabajar con ellos.
SZZY: Un montón de frases bonitas sobre POO, encapsulación y herencia... Todo esto es bueno, pero la principal ventaja de la POO sobre otros estilos de programación es el almacenamiento de todos los datos (campos de la clase) y las funciones de trabajo con estos datos (métodos de la clase) en un solo lugar (clase) - en libro es la encapsulación. El uso posterior de la programación orientada a objetos depende de las tareas, si la tarea permite escalar las clases, entonces se necesitará una jerarquía y habrá clases base y sus descendientes - si se usa, depende de usted
También puedes "encapsular" todas las propiedades de un objeto en un array. También puede especificar las relaciones entre los objetos a través de las propiedades específicas de los punteros. Hay un orden allí, porque cada propiedad está indexada y su valor se almacena en una celda específica. Los objetos en sí están encapsulados en el núcleo. El acceso es más sencillo: por número de objeto y número de propiedad. Las transiciones entre los objetos del mismo control se realizan a través de los punteros de las propiedades.
¡esto no es conveniente en primer lugar!
Además, ya has escrito más arriba sobre la legibilidad del código (así como más arriba has mencionado la velocidad - la velocidad de ejecución, depende de algo más, no del estilo de programación)
en general, como en todas partes - no lo sabrás hasta que lo intentes, empieza a escribir en estilo OOP, obtendrás acciones específicas y preguntas específicas, un ejemplo ya está en este hilo
Si hablamos de IA, también hay que separar los datos del trabajo con ellos, con OOP será más fácil hacerlo
SZZ: ¿Qué es mejor en OOP? Por ejemplo, tenemos diferentes tipos de datos, digamos configuraciones del Asesor Experto en MQL, y estas configuraciones tienen repeticiones en bloques. Tomamos un bloque de configuraciones y describimos campos de clase para transferir estas configuraciones a la clase, es más fácil crear un constructor con parámetros, y luego escribir métodos que trabajen con estas configuraciones de EA. Una vez hecho todo esto, creamos un array de instancias de la clase, o incluso sólo unas pocas instancias de la clase ("variables de tipo de clase") y ya está - el problema se resuelve escribiendo una clase, no creando varios arrays, creando métodos para identificar cada array, creando un grupo de funciones que, además de hacer cambios en los arrays, no son suficientes para estropear los datos que no deben ser procesados en esta llamada....
ZZZY: imho, OOP es sólo conveniente, hay una cierta leyenda de que no hay necesidad de usar OOP si no hay herencia... sin comentarios, va a ser una discusión espumosa, sin mí
¡esto no es conveniente en primer lugar!
Además, ya has escrito más arriba sobre la legibilidad del código (así como más arriba has mencionado la velocidad - la velocidad de ejecución, depende de algo más, no del estilo de programación)
en general, como en todas partes - no lo sabrás hasta que lo intentes, empieza a escribir en estilo OOP, obtendrás acciones específicas y preguntas específicas, un ejemplo ya está en este hilo
Si hablamos de IA, también hay que separar los datos del trabajo con ellos, con OOP será más fácil hacerlo
SZZ: ¿Qué es mejor en OOP? Por ejemplo, tenemos diferentes tipos de datos, digamos configuraciones del Asesor Experto en MQL, y estas configuraciones tienen repeticiones en bloques. Tomamos un bloque de configuraciones y describimos campos de clase para transferir estas configuraciones a la clase, es más fácil crear un constructor con parámetros, y luego escribir métodos que trabajen con estas configuraciones de EA. Una vez hecho todo esto, creamos un array de instancias de la clase, o incluso sólo algunas instancias de la clase ("variables de tipo de clase") y ya está - el problema se resuelve escribiendo una clase, no creando varios arrays, creando métodos para identificar cada array, creando un grupo de funciones que, además de hacer cambios en los arrays, no son suficientes para estropear los datos que no deben ser procesados en esta llamada....
ZZZY: imho, OOP es sólo conveniente, hay una cierta leyenda de que no hay necesidad de usar OOP si no hay herencia... sin comentarios, va a ser una discusión espumosa, sin mí
Cómodo o no, cuestión subjetiva. Prefiero una disposición tabular de los datos. Otros lo prefieren en forma de racimo de uvas o de árbol. Otros lo prefieren como un racimo de uvas o un árbol. Pero, pensaré seriamente en tus palabras e intentaré comprender los principios básicos del trabajo con datos en POO.
En POO, un "objeto" es una referencia a una clase en la que se declaran sus campos (propiedades). Entiendo un objeto como un conjunto numerado de propiedades, cada una de las cuales es una celda de un array. Esa es la diferencia.
HH es decir, si hay una clase en el programa, pero no hay instancias de ella, el compilador ignorará (no notará) esa clase.
Una vez te dije que un array de punteros a arrays de punteros es una tabla bidimensional. Una lista son las filas, las listas que yacen en la primera son las columnas. Pueden tener sus propias listas. Y así hasta que se ponga el sol. Esta es la jerarquía que está buscando. Y lo realiza una sola clase.
En teoría, sí. Pero es necesario organizar de tal manera que las transiciones entre los eslabones jerárquicos (condicionalmente - inducción y deducción, es decir, de lo particular a lo general y viceversa) se realicen como una cadena. Es decir, el orden de los punteros debe estructurarse de forma especial para permitir moverse en cualquier dirección (correcta), sin excesivas "vueltas" y "saltos" en el bucle. Por lo tanto, es probable que no funcione una simple disposición en forma de tabla de los punteros.
Añadido:
Pero podría funcionar. Todavía no lo sé.
Tenemos que poner en práctica estas preguntas, de lo contrario no podremos ver lo que es conveniente y lo que parece inconveniente )))).
He aquí un ejemplo trivial, que se utiliza en MQL ciento cincuenta veces - la determinación de una nueva barra:
Bien, este es un código que funciona, pero ¿qué pasa si necesito definir una nueva barra para 2 TFs? ¿Y qué pasa si quiero utilizar todos los TFs del terminal?
sería así en OOP:
y todo lo que tengo que hacer ahora es declarar varias instancias de la claseCNewbar - ¿cómo? incluso a un array, incluso a varias variables, pero he protegido los datos de un cambio accidental con OOP
Ya he resuelto este problema públicamente. La idea era crear una tabla con todos los símbolos y todos los plazos y hacer un bucle a través de ella, fijando los eventos de una nueva barra. Después de la primera llamada de cualquier función de este evento, su bandera se borra de la tabla. No puedo juzgar cuánto más complicado es que en OOP. Pero, de hecho, es una solución bastante simple y conveniente.
Peter, tienes que entender claramente que a la clase en sí no se le asigna memoria, aunque haya instancias de otras clases dentro de la clase como sus propiedades. Por lo tanto, no puede haber ninguna referencia a la clase, sino sólo al objeto de la clase. La memoria se asigna cuando se declara (crea) una instancia (objeto) de una clase.
En teoría, sí. Pero es necesario organizar de tal manera que las transiciones entre los eslabones jerárquicos (condicionalmente - inducción y deducción, es decir, de lo particular a lo general y viceversa) se realicen como una cadena. Es decir, el orden de los punteros debe estructurarse de forma especial para permitir moverse en cualquier dirección (correcta), sin excesivas "vueltas" y "saltos" en el bucle. Por lo tanto, una simple disposición de tabla de punteros probablemente no funcionará.