Petición inválida - acaba de empezar y no puede resolverlo... - página 6
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
Pues yo he escrito uno para mí, pero para cuatro.
¿Así que usted personalmente ha escrito una biblioteca universal, separada de la lógica de negocio del EA y que puede ser utilizada en cualquier EA?
Yo tampoco creo en eso. Por supuesto que el código del manejador de la respuesta del servidor estaba allí, pero todo dentro de la lógica del negocio, no como una biblioteca universal.
¿Así que has escrito personalmente una biblioteca universal, separada de la lógica de negocio del EA y que puede ser utilizada en cualquier EA?
Yo tampoco creo en eso. Por supuesto, el código del manejador de la respuesta del servidor estaba allí, pero todo dentro de la lógica del negocio, no como una biblioteca universal.
Sí, puedo probarlo. Por un precio, por supuesto.
Es decir, tampoco hay una biblioteca para MT4.
No era tan difícil de probar.
Es decir, tampoco hay una biblioteca para MT4.
No era tan difícil de probar.
Renat, tengo la sensación de que el uso de la biblioteca estándar entra en el coro: "OOP o no OOP".
De lo contrario, no puedo entender por qué la gente tiene la firme creencia de que un envoltorio OOP, que simplifica las operaciones comerciales, no debe ser utilizado.
Algunos reclaman una envoltura que haga toda la lógica, maneje los errores, repita las consultas, etc. Y al mismo tiempo su uso es supuestamente peligroso y hay un error en cada línea...
Es decir, está ahí.
todos los errores son manejados por la lógica del negocio.
Utiliza la propiedad de sincronización en MT4, lo que simplifica el procesamiento hasta cierto punto, pero sus métodos no garantizan el 100% de los casos. Probablemente el 95% y eso es puramente su biblia en la que se basa todo el proceso de negociación.
Pero MT5 es muchas veces más complejo en términos de manejo de códigos de retorno + asincronía.
Estás pidiendo lo imposible a un envoltorio. La biblioteca estándar no es lógica de negocio. Es una envoltura "sobre" las funciones de la terminal. Un envoltorio sobre el relleno de una chocolatina.
Es una interfaz fácil de usar que se encarga de parte de la rutina. Asumiendo el mismo tipo de código. No te comes un envoltorio de papel y te quejas porque no es comestible. :)
Pero el envoltorio no puede garantizar nada, ya que eres tú el que actúa como garante. Su lógica empresarial. :)
Al igual que la función de impresión no puede garantizar el espacio libre en el disco y los errores de registro. Tienes que usar otras funciones para el manejo de errores y son específicas para cada caso.
-Alexey-, vamos a charlar sobre los defectos específicos y tú expresas los defectos específicos que te gustaría arreglar.Si quieres, puedes repasar cada código de retorno y ver las principales situaciones posibles.
Responde a las preguntas:
- ¿por qué iba a arrastrar todos estos 61 métodos detrás de mí? ¿Es racional?
La pregunta va en el plano de si se necesita o no la programación OOP. No puedo responder de forma inequívoca.
En mi práctica utilizo la POO para los modelos de alto nivel.
Por supuesto, utilizo mucho en mi base sólo en las funciones.
De la misma manera, cuando utilizo una clase OOP contiene un montón de cosas innecesarias para alguna tarea en particular. Es como la funcionalidad de la biblioteca de dibujo kanvas. Hay líneas, cuadrados y texto. Pero no hay nada que discutir: si esta clase debe tener una plaza o no. Simplemente está ahí. Para una tarea concreta.
Hay demasiados problemas que intentan resolver en una sola clase.
te equivocas. No están resolviendo ningún problema en absoluto. se han envuelto alrededor de RUTINA. es difícil de entender.
Por lo tanto, el tratamiento de errores debe ser para todas las tareas que se resuelvan.
No puede estar ahí. Ya que la biblia no resuelve ningún problema. Simplifica la RUTINA. Eso es todo. No puede hacer más, y no necesita ser complicado.
La solución es bastante sencilla: dividir una clase engorrosa en varias más pequeñas, en función de los problemas a resolver:
En este caso, sólo incluiré las clases que se ajusten a mi estrategia y nada superfluo. Y será mucho más fácil implementar el manejo de errores de lo que es ahora.
Bueno, no es una rutina envolvente. Ya es un solucionador de problemas con la lógica específica de tu experto.
No se puede prever la gestión de errores ni siquiera en una sola función - de apertura o de cierre. Siempre se encuentran 1001 casos, cuando los errores previstos no caben y hay que hacer otra cosa.
Si conoce una función universal para todas las situaciones, por favor, muéstrela. No puedo ni imaginar cómo es posible prever de antemano todos los posibles manejos de errores, sin conocer la lógica de un EA en particular.
Incluso si hago tal función - contradice todas sus palabras superiores - "usted ha hecho demasiado ruido otra vez".
Y si aplica su método de escribir código a través de macros con dirección (ORDER_TYPE_BUY / ORDER_TYPE_SELL), entonces las clases serán bastante compactas.
¿Dónde está todo?
Pero las macros tampoco tienen manejo de errores, sino que son manejadas por la lógica de negocios de un Asesor Experto en particular en un error particular. No es tan difícil entender que no hay situaciones universales.
Si Renat aprendiera a escuchar las sugerencias del foro y tratara de captar el significado de las mismas, MT5 ya estaría muy por delante de donde se encuentra hoy en esta fase de desarrollo.
Renat sigue repitiendo: estamos en un foro técnico, no podemos hablar aquí de cosas abstractas.
Así que, por favor, danos algunos detalles. Consideremos el pliego de condiciones, las funciones comerciales que necesita y los posibles errores y cómo manejarlos. ¿ok?
Responde a las preguntas:
- si sólo necesito colocar una orden de mercado, o una orden pendiente, ¿por qué voy a arrastrar todos esos 61 métodos detrás de mí? ¿Es racional?
- Si tengo una posición abierta y sólo necesito fijar los stops, ¿por qué voy a arrastrar toda esa funcionalidad con 61 métodos? ¿Es racional?
- Si tengo una posición abierta con stops que se activarán cuando el precio alcance su nivel, ¿por qué debo arrastrar todos estos 61 métodos? ¿Es racional?
Nadie te lo prohíbe:
¿Qué sentido tiene "separar las operaciones de los oficios en diferentes clases"?
Es lo mismo que si tuvieras diferentes EAs para abrir, cerrar y modificar. Parece que es posible, pero nadie lo hace (salvo raras excepciones, tareas especiales).
Y me gusta mucho la frase "si sólo necesito colocar una orden de mercado o una orden pendiente, ¿por qué debo arrastrar todos esos 61 métodos conmigo? ¿Es eso racional?"
Pues habrá unos 100kb de sobrecarga de memoria por Asesor Experto. Cielos...
Por cierto, he aquí una encuesta ¿Utilizas la biblioteca estándar para las operaciones comerciales?
Francamente, no debería haber salido con mi post.