Preguntas de POO (Programación Orientada a Objetos) - 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
Como siempre, quería aprender, pero seguro que hay quien no tiene nada más que decir que ser inteligente...
Escribí un simple ejemplo para desmontarlo, no sé cómo escribir más competentemente con OOP ... Es sólo un ejemplo, si usted sabe cómo escribir un código similar correctamente y OOP entonces por favor escriba, para que yo y otros puedan aprender ...
La POO comienza con la búsqueda de un objeto. Si no hay objeto, no hay OOP.
Normalmente, un objeto son algunos recursos, datos.
Sólo hay que escribir y observar cómo escriben los demás. Entonces lo descubrirás por ti mismo. También puedes leer libros de texto. Hay muchos en Internet.
La POO comienza con la búsqueda de un objeto. Si no hay objeto, no hay OOP.
Normalmente, un objeto son algunos recursos, datos.
Sólo hay que escribir y observar cómo escriben los demás. Entonces lo descubrirás por ti mismo. También puedes leer libros de texto. Hay muchos en Internet.
Recomendar un par de libros de texto por favor ... Lo más fácil y útil en su opinión...
Recomendar un par de tutoriales por favor ... Lo más fácil y útil en su opinión...
Grady Buch. "Análisis y diseño orientado a objetos. Con ejemplos de aplicaciones en C++".
Ire Paul (a veces escrito Ira Paul) "Programación orientada a objetos en C++".
1) No está relacionado con la POO, pero se debería añadir un gestor de errores de operaciones comerciales(OrderSend(), OrderDelete(), OrderModify() )...
Para que sea relevante para la POO - hágalo como un método de clase virtual (para anularlo en clases descendientes, añadiendo el procesamiento de otros códigos).
2) Todos los métodos de la clase que en las clases descendientes pueden funcionar de manera diferente que ahora - hacerlosvirtuales.
El primer candidato es openorders().
La desventaja es que en los métodos virtuales no se puede cambiar el número y tipo de parámetros.
El lado positivo es que los "antiguos" Buy, Sel, BuyStop , etc. podrán llamar a los "nuevos" (alterados en la clase hija) openorders()
3) Que los nombres sean más bonitos de una vez. OpenOrders en lugar de openorders, por ejemplo.
4) Si la terminología es para llamar a algo, entonces se utiliza una terminología similar.
Si vender = SELL, entonces se llama Sell o SELL (es decir, SellStop en lugar de SelStop)
5) Debe eliminar todas las constantes (500, etc.) de la clase.
Que se tomen de las variables o se pongan como parámetros de los métodos.
Ahora recuerdas unas 500 incrustaciones en openorders(), pero más adelante te olvidarás de ello o escribirás muchos búhos usando estas clases y será difícil cambiar algo.
Lo más difícil de arreglar son los errores arquitectónicos.
Y es el esqueleto que estás creando ahora (si no es sólo un ejercicio).
6) No pongas todo en una sola clase.
Haz una clase clOrder y pega con ella SetSL, CloseOrder, GetSL, GetProfit, SetTP, GetTP , etc.
Y en la clase clTrade , añada un array/lista de órdenes, un símbolo y propiedades del símbolo(TICKETSIZE, POINT, TICKETVALUE, MINLOT, MAXLOT, STOPSTEP, LOTSTEP, LOTSIZE , etc.).
Si adjunta Ask y Bid (como propiedades de un símbolo), no olvide actualizarlos en OnTick().
Para RefreshRates(), haga un binding para que después de la actualización de las variables МТ se llame a las propiedades Ask y Bid (también he comprobado el estado de las órdenes, quien abrió y quien cerró. Los cerrados se eliminan de la lista de pedidos).
Puede añadir el horario (en primer lugar, hacer una clase) y el trailing stop (también hacer una clase separada).
PD: Lo hice todo el fin de semana (hice biblioteca para oficios), pero esta vez me decidí sin clases (sólo estructuras, arrays de estructuras y funciones que funcionan con todo ello).
También hay un horario para cada día (ya que Alps on gold tiene un descanso cada día de 0:00 a 1:00). En los últimos 2 minutos de la negociación, el verificador de horarios cierra todas las operaciones y cancela todas las órdenes.
Y en la última hora de la negociación - cierra las operaciones perdedoras, cancela las órdenes y trilla las rentables. También he hecho un trailing stop. Un tipo, pero que se ajusta a diferentes símbolos debido a diferentes parámetros.
El esquema es el siguiente - símbolos (con sus propios campos), órdenes (con sus propios campos), horarios (con sus propios campos) y un Asesor Experto con sus propios campos (magik, etc.) que se refiere a un símbolo y tiene una lista de órdenes y una lista de horarios.
La parte superior de la jerarquía es la lista de Asesores (la combinación símbolo+magia debe ser única).
Recomendar algunos tutoriales por favor ... El más sencillo y útil en su opinión...
Ahora aparecen en CodeBase ejemplos escritos con POO. De VOLDEMAR, por ejemplo ))))
En realidad, su https://www.mql5.com/ru/code/11159 es lo que me ha inspirado a reescribir mi biblioteca comercial para las estructuras.
He decidido esperar con las clases - no veo el sentido de usarlas en MQL .
¿O es estándar sólo en MQL5, y sólo se ha tomado de allí en el nuevo MetaEditor?
Ahora aparecen en CodeBase ejemplos escritos con POO. De VOLDEMAR, por ejemplo ))))
En realidad, su https://www.mql5.com/ru/code/11159 es lo que me ha inspirado a reescribir mi biblioteca de comercio para las estructuras.
He decidido esperar con las clases - no veo el sentido de usarlas en MQL hasta ahora.
Sí, escribí esto, pero aparte de transferir las funciones a una clase, aún no he entendido nada más,
Sí, escribí eso, pero aparte de transferir funciones a una clase no he entendido nada más,
3(+1) Principios OOP:
1) Encapsulación. Es decir, almacenar variables, pseudovariables (llamadas "propiedades del objeto" o simplemente "propiedades") en el propio objeto. Es decir, si una clase se declara correctamente, sus datos no pueden ser modificados desde el exterior.
Sólo utilizando funciones de la propia clase (denominadas "métodos de la clase" o simplemente "métodos"). Se necesita para no sólo asignar un valor a una variable, sino para realizar alguna acción en relación con el cambio de esos campos.
Y esta es la principal (en mi opinión) utilidad de introducir OOP en MQL, en lugar de portar funciones (las funciones de mi biblioteca de comercio reciben el índice del EA como uno de los parámetros y trabajan con el EA seleccionado, incluyendo su matriz de órdenes).
Nadie puede entrar en los datos de una clase creada por ti (si no hay código fuente) y luego quejarse de que tu código tiene errores.
2) Herencia. Cuando se crea una clase antecesora, hereda todos los campos y métodos de la clase antecesora (hay un tipo privado para los campos y métodos que no se pueden ver en las clases antecesoras, pero lo omitimos por ahora).
Y aquí, en la fase de diseño del objeto, hay que pensar claramente en la arquitectura: cómo se utilizará la clase, qué campos contendrá, cómo deben ser visibles en las clases descendientes, etc.
Se utiliza en potentes sistemas y bibliotecas de clases, para tareas que personalmente no veo en las tareas comerciales. Pero tal vez alguien lo necesite. Se pueden hacer clases descendientes con diferentes trailing stops, por ejemplo.
Por eso - no hay constantes dentro de los métodos, todo debe establecerse externamente a través de los métodos apropiados (normalmente comienzan con .Set) o directamente como parámetros de los métodos. A eso me refiero con tus 500.
3) Polimorfismo. Lo que escribí un par de posts más arriba - cuando una función remodelada en una clase descendiente openorders() llamará libremente a las antiguas funciones Buy().
Un ejemplo de polimorfismo es el cálculo del área de una figura geométrica para diferentes formas.
Se calcula de una manera para un círculo y de otra para un cuadrado. Pero en cualquier caso - llamando a Figura.GetSquare() obtendremos el área de una forma particular heredada de una clase base (si no olvidamos declarar Square() ).
Una vez más, se requiere cierta cualificación para crear la arquitectura de la clase base. Por ejemplo, olvidar declarar Square() como virtual hará imposible llamar a Square de forma genérica (tendrá que comprobar el tipo de clase antes de cada llamada y llamar a su implementación de Square).
Algunas personas recomiendan hacer virtuales todos los métodos excepto los constructores (yo opino lo mismo si no se ve el horizonte de lo que puede llegar a ser esta clase al crearla). Lo principal es que los destructores deben ser también virtuales.
Actualización:
================
4) Abstracción (como piden los compañeros, aunque cuando estudié POO (en los años 90) no se consideraba un principio (pues de hecho - sólo se derivan de los tres primeros), y en el artículo (ver enlace más abajo) se escribe sobre ello, pero no está en el título del artículo, sólo hay 3).
En la aplicación práctica es crear una clase base "vacía" (donde se declaran los métodos, pero no hacen nada). En algunos lenguajes, un método puede ser marcado como abstracto, lo que significa que en una clase descendiente debe ser necesariamente superpuesto (es decir, se añade un método que hace algo).
===================
P.D.: puedes leer brevemente, sin entrar en materia, aquíPPS: No quiero ofender a nadie, pero cuando pregunté en Trabajo para escribir una biblioteca comercial, sólo 1 persona respondió que la tiene y la usa.
5 programadores de MQL (en Skype) dijeron que no tenían ni idea de lo que debía contener y que copiaban y pegaban las funciones necesarias de uno de sus búhos a otro. Incluso meten RefreshRates() entre fragmentos de código que no cambian nada y no pueden ejecutarse más que unos pocos milisegundos. Y el código posterior no depende del cambio de Ask y Bid y (quizás) de los tipos de órdenes.
Por lo tanto, para los programadores de MQL que no han trabajado con OOP en otros lenguajes de programación antes, la OOP en MQL no será útil. Como mucho, ocultará los datos de los cambios externos (lo que tampoco está mal).
3) Los 3 principios de la POO:
1) Encapsulación. Es decir, el almacenamiento de variables, pseudovariables (denominadas "propiedades del objeto" o simplemente "propiedades") en el propio objeto. Es decir, si una clase se declara correctamente, sus datos no pueden
2) Herencia. Cuando se crea una clase antecesora, hereda todos los campos y métodos de la clase antecesora (hay un tipo privado para los campos y métodos que no se pueden ver en las clases antecesoras, pero lo omitimos aquí por ahora).
3) Polimorfismo. Lo que escribí unos posts más arriba - cuando se remodela en una clase descendiente la función openorders() llamará con seguridad a las antiguas funciones Buy(), etc.
Un ejemplo de polimorfismo es el cálculo del área de una figura geométrica para varias formas.
Se calcula de una manera para un círculo y de otra para un cuadrado. Pero en cualquier caso, llamando a Figura.GetSquare() obtendremos el área de una forma particular heredada de la clase base (a menos que hayamos olvidado declarar Square() ).
¡¿Dónde está el cuarto?! ¿Dónde está el resumen? Inmerecidamente olvidado :-(
Añade.