Discusión sobre el artículo "Biblioteca para el desarrollo rápido y sencillo de programas para MetaTrader (Parte XXVII): Trabajando con las solicitudes comerciales - Colocación de órdenes pendientes" - página 4
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
¿Por qué los envían una vez por segundo? ¿Para inundar el servidor comercial?
Y necesito objetos completos para seguir realizando lo que he planeado. Pero tú aún no eres consciente de ello, e intentas ofrecer formas ineficaces de resolver una pequeña parte de la tarea para seguir trabajando. Pero aquí todo está relacionado, y el concepto general es el mismo: las otras cosas planeadas en el futuro dependen de esta pequeña parte.
De todos modos, gracias por tu opinión - cualquier opinión es útil y tiene sentido.
ZЫ. Y, sí - no es terrible escribir un lío de código que funcione en lugar de reescribir constantemente soluciones incompletas escritas irreflexivamente para las siguientes tareas.
Bueno, si las necesitamos, las necesitamos. Será interesante averiguar por qué.
ZЫ. No sería terrible si se librara de cambios y rediseños, pero de hecho no lo hace. Qué Objeto o no Objeto - todo el mismo desarrollo del concepto obliga a rediseñar un montón de cosas.
Bueno, si se necesitan, se necesitan. Tendré curiosidad por ver para qué.
ZY. No sería terrible si salvara de cambios y rediseños, pero de hecho no lo hace. Objeto o no objeto - de todos modos el desarrollo del concepto obliga a rediseñar muchas cosas.
No estás separando los conceptos de "rediseñar" y "extender". Rediseñar es tirar una cosa ya hecha a la basura y escribir una nueva desde cero. Y extender es añadir nuevas funcionalidades a lo ya hecho.
En la mayoría de los casos, aquí sólo se añade, no se reescribe de artículo a artículo.
Pero cuando se crea algo nuevo desde cero, sí, hay mucha reescritura. Pero eso es entre bastidores en los artículos. Las únicas dos excepciones - en el principio había pequeñas modificaciones de los ya publicados para ampliar aún más la funcionalidad de todos los componentes de la biblioteca, y ahora - en un primer momento - primero probar la solución en el código simplificado, y luego - a través de un artículo - hacer objetos de pleno derecho-comercioconsultas, y luego - hacer una clase de trabajo con ellos.
Ahora todo se hace en un solo lugar - en la clase de comercio. Pero no debería estar allí - a pesar de que es el comercio, pero no es el comercio métodos - es una forma de gestionar los métodos de comercio.
No estás separando los conceptos de "rehacer" y "ampliar". Rediseñar es tirar el ya hecho y escribir uno nuevo desde cero. Y extender es añadir nuevas funcionalidades al ya hecho.
En la mayoría de los casos, aquí sólo se añade, no se reescribe de artículo a artículo.
Pero cuando se crea algo nuevo desde cero, sí, hay mucha reescritura. Pero eso es entre bastidores en los artículos. Las únicas dos excepciones - en el principio había pequeñas modificaciones de lo ya publicado para ampliar aún más la funcionalidad de todos los componentes de la biblioteca, y ahora - en un primer momento la solución se está probando en un código simplificado, y luego - a través de un artículo - hacer objetos de pleno derecho - las solicitudes de comercio, y luego - hacer una clase de trabajo con ellos.
Ahora todo se hace en un solo lugar - en la clase de comercio. Pero no debería estar allí - a pesar de que es el comercio, pero no es el comercio métodos - es una forma de gestionar los métodos de comercio.
Comparto todo perfectamente bien y sé de lo que estoy hablando. Y usted no entiende lo que digo.
Tu preocupación por convertir todo en el mundo en un Objeto demuestra que no conoces sus límites conceptuales. No hay ninguna regla en la programación orientada a objetos que exija convertir todo en un objeto, pero parece que tú no la conoces.
Piensa en el tiempo que pasarás tratando con Objetos, cuya necesidad ya está siendo socavada por la solución concisa y lista que te señalé. ¿Qué más se te puede ocurrir con esto? No tengo suficiente imaginación. Tal vez la tenga. Pues adelante.
A la pregunta de qué puede convertirse en Objeto y qué no.
1. Una solicitud de operación es un objeto.
2. Una solicitud de operación pendiente no lo es. ¿Por qué? Porque si la convertimos en un objeto, será una copia exacta del objeto solicitud de operación con una diferencia: sus criterios de repetición y eliminación. Esta es una diferencia demasiado pequeña para hacer que una solicitud de operación diferida sea un "paquete" de una solicitud de operación.
...Tú creas muchos Objetos pequeños y sencillos, yo uno grande y muy complejo....
Peter, ¿es esto superclase? ¿Se puede meter lo que no se puede meter? :-) Escriben en los libros que no es bueno.....
Me gustaría indicarle a Artyom que cuando Anatoly escribió una serie de artículos sobre gráficos, dio la estructura de interrelaciones entre clases (léase jerarquía). Por ejemplo.
Artyom, has hecho un gran trabajo. Puedes escribir todo un libro de texto sobre ello. En algunos puntos es incluso más detallado que la Documentación. Y eso está muy bien. Pero a veces no hay suficientes ilustraciones en el material. Imho, por supuesto...
Peter, ¿qué es esto, superclase? ¿Se mete lo que no se puede meter? :-) Los libros dicen que no es bueno....
Me gustaría indicarle a Artyom que cuando Anatoly escribió una serie de artículos sobre gráficos, dio la estructura de interrelaciones entre clases (léase jerarquía). Por ejemplo.
Artyom, has hecho un gran trabajo. Puedes escribir todo un libro de texto sobre ello. En algunos puntos es incluso más detallado que la Documentación. Y eso está muy bien. Pero a veces no hay suficientes ilustraciones en el material. Imho, por supuesto...
Peter, ¿qué es esto, superclase? ¿Se mete lo que no se puede meter? :-) Los libros dicen que no es bueno....