Una pregunta para los expertos en POO. - página 5
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
Todas las listas ya están equipadas con una búsqueda binaria. No se trata de recorrer las listas una a una, sino de filtrar por la propiedad buscada. Como resultado, obtenemos el índice del artículo que buscamos.
Cuando se crea un objeto de clase, además de asignar memoria para todas las propiedades (variables) de la clase, se inicia uno de los constructores (puede haber más de uno). Los constructores pueden ser no paramétricos (por defecto), paramétricos (cuando se especifican algunos parámetros al crear una instancia de una clase, o un constructor de copia, cuando se especifica otra instancia de la clase como parámetro de una instancia de la clase.
Ya he resuelto esta tarea 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.
como se ha escrito más arriba, todo es relativo.... usando la última toma del clip...
¿has miradola librería estándar de la entrega de MT? es todo estilo OOP, aquí hay 2 opciones o los programadores de Metakvot son profesionales y usan estilos comprensibles o... Su versión ;)
como se ha escrito más arriba, todo es relativo.... usando la última toma del clip...
¿has miradola librería estándar de la entrega de MT? es todo estilo OOP, aquí hay 2 opciones o los programadores de Metakvot son profesionales y usan estilos comprensibles o... Su versión ;)
Todavía no estoy muy versado en OOP. Me hablan de listas pero no sé con qué "comen". Cómo se anuncian, cómo se accede a ellos, cómo se modifican... Para mí, una lista es simplemente un array dinámico sin ninguna sintaxis adicional. Un objeto es un conjunto de propiedades en un array. Y en OOP - Object es una clase completa. Herencia - vinculación de objetos. Acceso a las propiedades del objeto a través de las referencias nombradas. Así que, en mi caso, todo es mucho más sencillo y, por lo tanto, me resulta difícil comparar las características y la eficacia. Tengo que profundizar en ello.
Pero una cosa he aprendido. No se puede entender y utilizar una sola entidad del concepto de POO sin entender toda la POO y pasarse a ella por completo. Es OOP o lo que quieras. Utilizar uno de sus prácticos mecanismos probablemente no funcionará.
Utilizar simplemente uno de sus prácticos mecanismos probablemente no funcionará.
La POO puede coexistir con el estilo procedimental sin problemas, pero las funciones deben ser bloques de código completamente separados e independientes, es decir, todo lo que la función utiliza debe estar en ella o pasarse como parámetros a la misma
en general, como escriben en la Wiki, que la POO es una extensión del estilo procedimental
Pero hay una cosa que he entendido. No se puede entender y utilizar una sola entidad del concepto de POO sin entender toda la POO y sin pasar a ella completamente
se puede, di un ejemplo, y en el foro el 90% de las fuentes en estilo OOP son envolturas alrededor del estilo procedimental - sin herencia, sin abstracciones, sin ..... nada, sólo encapsulación, pero de todos modos es por lo menos conveniente - es conveniente tener un pedazo de código completamente transferible a otra tarea - después de todo todo dentro de una clase... ;)
con el estilo procedimental OOP sin problemas, pero las funciones deben ser bloques de código completamente separados e independientes, es decir, todo lo que utiliza una función debe estar en ella o pasarse como parámetros a ella
en general, como escriben en Wiki, la POO es una extensión del estilo procedimental
se puede, di un ejemplo, y en el foro el 90% de las fuentes de estilo OOP son envoltorios de estilo procedimental - sin herencia, sin abstracciones, sin ..... nada, sólo encapsulación, pero aún así es al menos conveniente - es conveniente tener un bloque de código totalmente portátil para otra tarea - todo dentro de una clase, ¿verdad? ;)
Sí, la portabilidad del código es una gran ventaja de la POO. En mi caso, sólo las funciones individuales son portátiles (y sólo en raras ocasiones), pero cuando construyo un gran mecanismo, nada es portátil. Al igual que los órganos humanos no son transferibles (sin intervención profesional). Mis mecanismos son más bien "organismos" en el sentido de que están divididos en grandes bloques, cada uno de los cuales realiza una serie de tareas. Por lo tanto, la portabilidad es casi inexistente. Sin embargo, estos bloques son muy fáciles de ampliar su funcionalidad. Lo "añades" con unas pocas líneas, y ¡voilá! - Los bloques realizan toda una capa de trabajo nueva para la que hay que escribir muchas funciones separadas. En definitiva, todo son ventajas. Bueno, el ámbito global es una herramienta increíblemente poderosa. El material con el que trabajan los bloques está absolutamente disponible para ellos y no hay necesidad de transferir nada. Todo lo necesario para trabajar ya está ahí. En definitiva, los enfoques son diferentes y cada uno tiene sus propias ventajas.
Todavía no sé mucho sobre OOP. Me hablan de listas y no sé con qué se "comen". Cómo se declaran, cómo se accede a ellos, cómo se modifican, etc... Para mí, una lista es simplemente un array dinámico sin ninguna sintaxis adicional. Un objeto es un conjunto de propiedades en un array. Y en OOP - Object es una clase completa. Herencia - vinculación de objetos. Acceso a las propiedades del objeto a través de las referencias nombradas. Así que, en mi caso, todo es mucho más sencillo y, por lo tanto, me resulta difícil comparar las características y la eficacia. Tengo que profundizar en ello.
Pero una cosa he aprendido. No se puede entender y utilizar una sola entidad del concepto de POO sin entender toda la POO y sin pasarse a ella por completo. Es OOP o lo que quieras. Utilizar uno de sus prácticos mecanismos probablemente no funcionará.
Peter, sólo tienes que probarlo. Y yo recomendaría probarlo exactamente en estructuras de lista porque ahí se pueden ver todas las ventajas de la POO en las tres direcciones - herencia, encapsulación y polimorfismo.
Debido a la herencia, se dispone de una única interfaz (un conjunto de funciones virtuales) para trabajar con los objetos dentro de una lista. Los objetos pueden ser simples o complejos, heredados de la base.
Por polimorfismo - se puede trabajar con objetos fundamentalmente diferentes con esta única interfaz.
Debido a la encapsulación - usted tiene SOLO esta interfaz, y no tiene acceso a ningún detalle de la implementación - en consecuencia, no puede arruinar algo. Además, sabes exactamente, no sólo cómo funcionan los objetos que están ahora, sino cómo interactuarán con tu código los objetos que aún no están escritos.
¿Estas listas están vinculadas a algo dentro de la OOP? ¿Qué "carga" llevan consigo? ¿Clases, constructores, interfaces...? Están integrados en el entorno de la clase, ¿no?
Bueno, el ámbito global es una herramienta increíblemente poderosa. El material con el que trabajan los bloques está absolutamente disponible para ellos y no es necesario transferir nada. Todo lo que necesitas para trabajar ya está ahí.
cuando se trata del ámbito global de las variables que se utilizan como parámetros de funciones o secciones de código, entonces.... imho, esta es la mejor manera de obtener un código completamente no transportable con la posibilidad de obtener errores ocultos que son imposibles de detectar después
SZZ: He modificado este tipo de códigos para los EAs de MT4 muchas veces, al principio cambié el nombre de las variables declaradas globalmente - luego hice cambios cuando vi errores de compilación, pero la última vez lo hice correctamente - añadí nuevos parámetros a las firmas de las funciones y luego eliminé las variables declaradas globalmente, porque si lograste modificar este código miserable una vez, tendrás que hacerlo todo de nuevo? - por desgracia soy perezoso, pero razonablemente perezoso )))))
cuando se trata del ámbito global de las variables que se utilizan como parámetros de funciones o secciones de código, entonces.... imho, esta es la mejor manera de obtener un código completamente no transportable con la posibilidad de obtener errores ocultos que son imposibles de detectar después
SZZ: He modificado este tipo de códigos para los EAs de MT4 muchas veces, al principio cambié el nombre de las variables declaradas globalmente - luego hice cambios cuando vi errores de compilación, pero la última vez lo hice correctamente - añadí nuevos parámetros a las firmas de las funciones y luego eliminé las variables declaradas globalmente, porque si lograste modificar este código miserable una vez, tendrás que hacerlo todo de nuevo? - por desgracia soy perezoso, pero razonablemente perezoso )))))
El código no es portátil, por eso es especial. No está pensado para ser portátil. Tiene otro propósito. Pues bien, el ámbito global de las variables es una poderosa herramienta para trabajar con mecanismos complejos. Sólo hay que saber utilizarlo. Cuando la gente me habla de errores y fallos ocultos, me confundo. Nunca he tenido ningún error relacionado con la visibilidad de las variables globales. En una palabra, en absoluto.