Mt4 Fin de soporte. - página 28
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
No sé si alguien lo ha sugerido, pero por qué no pasar todo lo que hay en MT4 a MT5, así todo el mundo pasaría.
George Merts:
Primero escriben las partes y luego las combinan en un todo, encontrando a menudo que las partes no son compatibles entre sí, lo que, por cierto, es lo que explica el deseo de "tener acceso a todas las variables disponibles".
No, no lo es. No se trata de tener acceso a todas las variables posibles, sólo a las que necesitas. Suelen ser variables de entrada y salida de diferentes funciones.
Añadir límites adicionales aquí hará que la legibilidad del código sea mucho más difícil y aumentará los posibles errores cuando algo no haya llegado porque se haya perdido en el camino debido a estos límites.
Ciertamente es comprensible el deseo de, al menos, tirar de OOP para algo útil, pero estos casos no suelen estar en el campo de la programación, sino en la esfera comercial, por ejemplo, para las horas de programación extra, la creación de interminables discusiones sobre la arquitectura de las interfaces y el pasatiempo agradable como en el tiempo de trabajo.
¿Existe, en principio, un ejemplo de ello? ¿Aunque no sea el suyo? Tengo profundas dudas. Al principio de los dos mil años dejé de contar el número de líneas de código de programa depuradas y en funcionamiento escritas por mí, porque superaba el millón: dejaba de ser interesante. Y nunca me he encontrado con la necesidad de crear mi propia clase, aunque la variedad y la escala de mis tareas eran muy diversas. He tenido que utilizar variables de tipo procedimiento cuando era necesario paralelizar el trabajo de varias personas, pero no más. ¿Por qué?
La cuestión es que la POO sólo puede aplicarse al empaquetado del código listo y sólo previene de él en la fase de escritura del código. Pero si no hay tal necesidad, tampoco se necesita OOP.
Vladimir:
Resulta que la POO impide el paralelismo automático de los cálculos. Hoy en día debe considerarse como un inconveniente muy serio, la perspectiva no es para OOP.
La perspectiva es en lenguajes como Systemverilog.
Está bien, excepto por el hecho de que la función isNewBar() no debería existir en absoluto. Es curioso que haya tanto baile en torno a algo tan trivial.
Es sólo una variable, y simplemente se compara con el tiempo de la barra; si todos los casos tienen éxito, entonces a la variable se le asigna el tiempo de la nueva barra al final. De lo contrario, sólo se asigna un intento a todos los casos.
Añadir límites adicionales aquí dificultará inmediatamente la legibilidad del código y aumentará los posibles errores cuando algo no llegue a algún sitio porque se haya perdido en el camino a causa de estos límites.
Es justo lo contrario: los límites te permiten no pensar en "para qué sirve esta variable, qué papel juega en este caso, no debería tenerse en cuenta".
El usuario sólo tiene acceso a lo que necesita considerar, y sólo a lo que puede cambiar. Estos son precisamente los errores "cuando se pierde algo por el camino", y surgen precisamente porque se dispone de demasiado y se "olvida algo por el camino". Con los intereses virtuales "truncados", esto es mucho más difícil de hacer.
Este es el ejemplo más sencillo: ganar una posición. Una posición es una orden abierta en MT4 o una posición abierta en MT5.
Si tiene acceso total, entonces al seleccionar una posición - el usuario tiene que recordar qué variables puede leer ahora, qué variables no son válidas en este momento, qué variables puede cambiar y cuáles no.
Con la interfaz, las cosas son mucho más sencillas. Lo tienes, y sólo tiene dos funciones: obtener el número de componentes, y obtener un puntero a un componente constante. ESO ES TODO. Con estas dos funciones - físicamente no se puede acceder a ninguna "variable extra".
Andrei:
Por supuesto, entiendo el deseo de al menos arrastrar de alguna manera la POO para algo útil, pero estos casos no suelen estar en el campo de la programación, sino en el ámbito comercial, como las horas extra de programación, las interminables discusiones sobre la arquitectura de las interfaces y el agradable pasatiempo en horas de oficina.
Y llegarás a esto tarde o temprano. Además, la encapsulación puede realizarse con un enfoque "puramente procedimental". Pero es más conveniente en el enfoque OOP, porque todavía se obtiene la herencia y el polimorfismo "automáticamente".
No sé si alguien lo ha sugerido, pero por qué no pasar todo lo que hay en MT4 a MT5, así todo el mundo pasaría.
El problema no es sólo que haya algo en el 4 que no esté en el 5. Y ni siquiera es la OOP.
5 no ha dado prácticamente nada a los operadores (no a los programadores, ni a los operadores de software, sólo a los operadores).
Formato propio de la historia, prohibición de la costumbre - pero estos dos puntos han asustado a todos los que comercian con la geometría. Y nada de "muchos TFs" (sin anuales, lol), las escalas en pips por barra los atraerán.
Una simple pregunta. ¿Qué muestra la "cuadrícula"? Tratar de averiguarlo te llevará a la recomendación de ir por libre y pedir lo que quieras.
Las MT son terminales para programadores. Esa es toda la respuesta.
La cuestión es que la POO sólo puede aplicarse al empaquetado de código listo, en una etapa de escritura de código sólo interfiere. Pero si no hay tal necesidad, no hay necesidad en OOP.
No, no lo es. Es justo al revés.
Las interfaces se definen inicialmente, incluso "antes de la fase de escritura del código". Las interfaces son, de hecho, la misma TdR para el programador. Todas las interacciones en Freelance se realizan utilizando TdR explícitos. Así, las interfaces virtuales son una especie de TOR, que es donde empieza la programación.
Simplemente, a mi entender, estás enfocando la esencia misma de la OOP de forma incorrecta. Primero escribes un montón de funciones, y luego tienes que "apretarlas" en el diseño OOP. Pero este es un camino equivocado. La forma correcta es la contraria: en primer lugar se definen las definiciones OOP, esos conjuntos de interfaces básicas entre los componentes del sistema. Y luego, uno por uno, cada componente se escribe siguiendo estas interfaces tan predefinidas.
Sí, a veces ocurre que al escribir el código descubrimos que la interfaz no ha previsto algo. Y entonces empiezas... "Ohhhh... En el enfoque procedimental - tendría acceso a todo esto, no tendría problemas para hacer lo que necesito, pero ahora - ¿cómo puedo acceder a estas variables?". Esto ocurre cuando en la fase de diseño de las interfaces no se ha tenido en cuenta algo. Esta es una situación muy desagradable: hay que añadir algunas interfaces adicionales o cambiar las existentes, lo que está plagado de errores. Por supuesto, esta situación debe evitarse.
Este es el ejemplo más sencillo: conseguir un puesto. Una posición es una orden abierta en MT4 o una posición abierta en MT5.
Si tiene acceso total, al seleccionar una posición - el usuario tiene que recordar qué variables puede leer ahora, qué variables no son válidas en ese momento, qué variables puede cambiar y cuáles no.
Con la interfaz, las cosas son mucho más sencillas. Lo tienes, y sólo tiene dos funciones: obtener el número de componentes, y obtener un puntero a un componente constante. ESO ES TODO. Con estas dos funciones - físicamente no puedes acceder a ninguna "variable extra".
Es justo lo contrario. A menudo, los usuarios necesitan conocer las variables internas para comprobar la calidad de los módulos, por ejemplo, y este no es el caso. Y se inventan formas especiales e ingeniosas para conseguir este acceso después. Así que, en principio, no hay información redundante, y quienes no la necesiten pueden simplemente no utilizarla.
Esto es exactamente lo contrario. A menudo, los usuarios necesitan conocer las variables internas para probar los módulos de calidad, por ejemplo, y este no es el caso. Y se inventan formas especiales e ingeniosas para conseguir este acceso después. Así, no hay información innecesaria, y quienes no la necesitan simplemente no la utilizan.
Si se necesita un "acceso astuto para conseguirlo", indica un diseño incorrecto del sistema.
Por ejemplo, si escribimos un generador de señales de entrada, no deberíamos tener acceso a la información relativa, por ejemplo, a la gestión del dinero.
Por supuesto, durante la depuración puede haber una situación, digamos, cuando no hubo entrada - debemos eliminar inmediatamente la situación, cuando ocurrió porque la gestión del dinero prohibió la operación (digamos, no hay suficiente margen). ¿Y cómo lo sabes por el generador de entradas? No tienes... no tienes acceso. Pero en este caso - es suficiente para asegurarse de que el generador ha establecido una señal de entrada, y funcionó correctamente. No hubo entrada - por alguna otra razón, que se encuentra fuera del generador de entrada. Averiguar la razón en este caso es realmente más difícil que si tenemos acceso a todas las variables de la gestión del dinero directamente. Pero, es mucho más peligroso que en la operación normal y rutinaria - nosotros, teniendo acceso a ellos - nos "metamos en el lugar equivocado".
Si se requiere un "acceso difícil de conseguir", es una indicación de que el diseño del sistema es defectuoso.
El desarrollo es, ante todo, un proceso natural de la mente.
En este proceso, las ideas se forman libremente e incluso de forma espontánea.
Seguir una POO dificulta la transformación del código libremente.
En el proceso natural de desarrollo, el propio código se va reduciendo y universalizando.
En el proceso natural, las funciones no se rompen sino que, por el contrario, crecen y se unen en grandes bloques.
Los bloques grandes resuelven una amplia gama de tareas.
La POO impide que se formen estos bloques, dejando el código fragmentado.
La POO crea accesos complicados, lo que aumenta constantemente el número de referencias a las variables.
Las ventajas de la granularidad se ven superadas por la dificultad de crear un mecanismo coherente.
La principal desventaja: la POO nos obliga a seguir el camino de dividir el código en una serie de funciones.
Para un humano es más fácil aceptar un código fragmentado, pero la fragmentación está contraindicada para cualquier mecanismo.