Una pregunta para los expertos en POO. - 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
el propio concepto de POO implica simplemente no escribir - no debe conocer la implementación del método (en su ejemplo return(SymbolSelect(m_name,select))
Imagina que en lugar de esta línea:
hay que hacer muchas consultas, varias comprobaciones, etc. - Esto le llevará tiempo para escribir su propia biblioteca y estudiar el material
Supongamos que su tarea consiste en utilizar un solo método de la solución ya preparada en forma de clase - usted crea una instancia de la clase (objeto) y utiliza el método Select(const bool select) ya preparado
Si no va a realizar estas operaciones, libere memoria = borre el objeto
Supongamos que su tarea es mostrar un botón, al presionarlo, usted activa/desactiva el símbolo en el reloj de mercado ---> cree su clase y encapsule la clase lista botón y la clase lista CSymbolInfo - la tarea está hecha
El paradigma de la programación orientada a objetos (OOP) sólo da información general sobre lo que se puede hacer con una clase - no quieres encapsular CSymbolInfo - pues hereda tu clase de ella
Creo, no lo entiendo y no lo acepto. Cuando tenga una tarea específica que no pueda hacer sin todas estas advertencias, entonces llegará la "iluminación mental" y la comprensión. Pero por ahora, desde mi punto de vista,no siempre están justificados los aparatos de lujo. No siempre quiere decir nunca. Me parece bien usar la clase Ctrade, pero no la tomo como se menciona arriba. Si la descripción de la función SymbolSelect en la documentación no es difícil de encontrar, en SB ya es difícil encontrar la descripción.
HH: "En pocas palabras", la esencia de la POO es una solución rápida a un problema dado sin conocer la implementación.
En ese caso, en lugar de conocer la implementación, hay que saber cómo llamar al método deseado, dónde encontrarlo, etc. ¿Se trata de un tipo de lenguaje en un lenguaje de programación?
Se puede entender si un proyecto necesita tener varias instancias de un objeto. Pero hasta ahora no he visto ninguna implementación de este tipo, salvo la demostración de Artem mencionada anteriormente. En ese caso está claro que es mejor, más fácil, más sencillo, pero no llegué a comprenderlo del todo precisamente por la falta de necesidad, de tarea. No tiene sentido cambiar el objeto por un solo uso de las funciones de mql5. Ese es mi razonamiento.
En ese caso, en lugar de conocer la implementación, hay que saber cómo llamar al método correcto, dónde encontrarlo, etc. ¿Es un tipo de lenguaje en un lenguaje de programación?
buscar en la documentación, todo lo que se publica va acompañado de manuales, por así decirlo, de ética
no es un estilo, es un paradigma - un concepto, reglas de etiqueta, nadie está obligado a escribir así, pero por alguna razón es el estilo más común
la esencia de la programación orientada a objetos es resolver rápidamente un problema determinado sin conocer la implementación
Se puede llamar a una función, pasándole una estructura con datos, y obtener una solución igualmente rápida sin conocer la implementación de la función.
Sí, pero su método será limitado en esto, en OOP también se puede heredar - incluso sin conocer la implementación y añadir a su tarea, lo primero que se me ocurre - Botón con bordes redondeados, hay toneladas de ejemplos en la web
SZZ: y la lógica de desplegar un objeto a través de los constructores es bastante útil.
Una clase es una descripción de un objeto. Bien. Contiene las propiedades y la funcionalidad del objeto. Bien. Todo esto está ordenado, abierto o protegido.
Entonces, el OBJETO en sí está fuera de la imagen. Es en el contexto de la clase. En el contexto de su nombre y descripción. Es decir, en POO, el Objeto, es exactamente un conjunto de atributos (no sólo propiedades, sino también elementos funcionales - métodos), pero más ordenados y encapsulados que yo. (Para mí tiene más sentido).
Hay que leer libros para darle sentido. Al menos VC++ en 21 días.
Te aconsejo que utilices MFC por primera vez, crea una aplicación de windows basada en CDialog, creando todo tipo de objetos y verás lo fácil que se gestionan.
Después de eso, tirarás tu aventura. Desgraciadamente.
Bueno, eso es poco probable. La cuestión es que he encontrado muy pocas diferencias conceptuales entre mi enfoque y la POO. Mi enfoque también está orientado a los objetos. Los objetos están encapsulados en el núcleo y tienen una representación muy específica. Están vinculados por punteros, formando complejos - elementos, ventanas... Si vas más allá de los gráficos y creas una forma diferente de núcleo que incluya más diversidad, será tan bueno como en OOP.
La diferencia de enfoques radica en el estilo de escritura del código, la sintaxis y los métodos de distribución de la funcionalidad. En mi enfoque la funcionalidad tiende a fusionarse, en OOP tiende a dividirse. La fusión de la funcionalidad garantiza el aumento de la eficiencia del sistema y una pequeña cantidad de sintaxis, mientras que la división de la funcionalidad facilita la portabilidad del código. Permite enchufar los módulos. En general, estas son las diferencias.
Por supuesto, mi enfoque aún no tiene esa amplia "objetividad". Pero, ya tengo pensamientos sobre cómo arreglar esto. Un núcleo es de un solo tipo y esto limita las propiedades almacenadas en él, pero un núcleo no tiene por qué ser una sola matriz. Puede ser un complejo de núcleos. La principal ventaja es la representación digital de los objetos, que no requiere una larga descripción, sintaxis adicional y fragmentación de la funcionalidad.
Pero, OOP es muy interesante para mí. Aprenderé de ello).Peter, por último busca en Google las clases, lo que son en el contexto de la asignación de memoria, las llamadas a métodos, es decir, en qué lo convierte todo el compilador. La mayoría de las preguntas se evaporarán por sí solas después de eso.
Se ha pensado mucho en el concepto de OOP, y esto es lo que hay:
Abstraigámonos de la sintaxis y los términos técnicos, dejando los conceptos de "Clase", "Objeto", "Propiedad", "Encapsulación", "Polimorfismo", "Herencia". Describiré la "raíz" filosófica del concepto.
La realidad es percibida por la conciencia a través de los prismas del "Espacio", el "Tiempo" y la "Materia" (así funcionan los órganos de los sentidos), y el "Objeto" es un resultado discreto de su continua interacción.
La multiplicidad de formas de interacción genera una variedad de objetos que son "plantados" por el inconsciente del sujeto en un determinado "marco". Este marco tiene una estructura ramificada y en cascada y está "construido" en el inconsciente, siendo uno de sus "arquetipos". El marco de trabajo toma nuevos objetos (información sobre ellos) que se distribuyen a lo largo de su estructura. De ahí viene el concepto de POO.Se trata de una distribución y unión consciente de los objetos imitando el "algoritmo" del inconsciente. Al dominar los métodos del propio pensamiento, el sujeto es capaz de simular su trabajo en el mecanismo de "rastreo" del cerebro: el ordenador. Aunque un ordenador no es más que una patética parodia de un cerebro, pero el propio hombre sólo percibe sombras del mundo objetivo. La cascada, arquetipo de ramificación, es un "patrón" de distribución de objetos, propiedades, procesos y toda la información dentro de nuestra memoria en general. Es una herramienta biológica para simplificar la percepción de la realidad, estructurando un modelo del mundo que nos rodea. Nos viene dada por la Naturaleza. La conciencia de nuestro propio mecanismo "natural" (es decir, inconsciente) de procesamiento de la información es un nivel de autoconciencia necesario parautilizar la POO.
Consideremos este arquetipo implícito, biológico y "arbóreo" que facilita la memorización, el aprendizaje y la percepción, en el contexto de su aplicación "artificial".En OOP, "producimos" objetos encapsulando sus descripciones en clases, donde establecemos sus propiedades y valores. Las relaciones de los objetos se reflejan en su clasificación, y se implementan a través de la herencia de propiedades y métodos de globales a privados. Prácticamente, se ve así: cada objeto privado es sólo un objeto y por lo tanto tiene todas las propiedades de sólo un objeto + sus propiedades privadas. Los objetos derivados tendrán sus propiedades privadas como sus propiedades comunes, pero tendrán sus propiedades privadas. Además, la cadena puede ramificarse indefinidamente. Lo mismo ocurre con los métodos de los objetos. Un método refleja una acción, una interacción, un proceso, un cambio de estados. Los métodos de los objetos se distribuyen de general a privado como las propiedades. Si existe un proceso general, cada forma discreta tendrá sus propias propiedades. Y esto es polimorfismo. Es decir, a diferencia de la sobrecarga, el polimorfismo proporciona una implementación privada diferente de una función subyacente conservando su mecanismo subyacente. Se trata de una herencia "funcional".
Como podemos ver, lo "arbóreo" en la programación orientada a objetos está en todas partes; sean cuales sean los esquemas que se inventen, seguirán obteniendo un "árbol"). Pero esto es correcto ya que sólo estamos copiando nuestros propios patrones inconscientes de trabajo con la información.
He estado pensando mucho en el concepto de OOP y es esto:
...Es difícil.
Peter, tienes que meterte en política. Aquí no se demandan esos talentos: decir mucho, de forma inteligente e incomprensible, y sobre nada.
...
Si comprendemos mejor cómo funcionan nuestras mentes consciente e inconsciente, podremos replicar su mecanismo en el ordenador. Simplemente me alejé de los detalles técnicos y miré la raíz del concepto.