Hablando de la OLP en el salón - página 7
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
ZS: por cierto, no he visto ni un solo deseo de cobertura de ningún tema en todo el hilo, como es habitual, la riña de siempre.
A juzgar por la elección del ejemplo inicial, existen dudas razonables sobre la calidad de la cobertura
¿Podemos ser más específicos sobre quiénes son y qué no han aprendido? Los moderadores no han aprendido a limpiar o algo más )
ZS: por cierto, en todo el hilo no he visto ni un solo deseo de abarcar ningún tema, como siempre, las disputas de siempre. Así que he decidido grabar vídeos en YouTube desde cero sobre cómo funciona la POO, al menos será de alguna utilidad. De todos modos, en un tiempo la rama terminará en el branch_sucker.
Seré más preciso: no han aprendido a utilizar la POO.
Alexey, creo que tú mismo eres consciente de que no puedes aprender simplemente POO. Hay un conocimiento formal de la POO: la herencia, la encapsulación, el polimorfismo - todos estos mantras se repiten a menudo, pero hay más daño que bien de alguien memorizarlos y aplicar violentamente y de manera inapropiada, como una clase de expertos para heredar de un módulo MM (hola a los desarrolladores de SB:).
En cuanto a MQL - es un lenguaje muy débil en términos de OOP: el control de tipos está completamente ausente (al menos implementaron el casting seguro), la reflexión está en su infancia y es muy limitada, no hay interfaces en absoluto. La pregunta que surge es: ¿qué tipo de OOP se puede enseñar en MQL? Qué decir, si los propios desarrolladores están haciendo tal lío en la Biblioteca Estándar que a veces da miedo.
Paraser más precisos: no hemos aprendido OOP.
Alexey, creo que es consciente de que no se puede aprender OOP sin más. Hay un conocimiento formal de la POO: la herencia, la encapsulación, el polimorfismo - todos estos mantras se repiten a menudo, pero hay más daño que bien de alguien memorizarlos y aplicar violentamente y de manera inapropiada, como una clase de expertos para heredar de un módulo de MM (hola a los desarrolladores de SB:).
En cuanto a MQL - es un lenguaje muy débil en términos de POO: el control de tipos está completamente ausente (al menos hicieron una conversión segura), la reflexión está en su infancia y es muy limitada, no hay interfaces en absoluto. La pregunta que surge es: ¿qué tipo de OOP se puede enseñar en MQL? Qué decir, si los propios desarrolladores moldean tal joroba en la Biblioteca Estándar que a veces da miedo.
Sí, es débil, pero todavía se pueden hacer proyectos de gravedad media. El SB ha sido realizado por diferentes personas con distintos niveles de formación. Y le falta lo esencial, yo sigo usando su CDiccionario, y es lo más debido.
¿Y ahora qué, acostarse y morir? )) Al fin y al cabo, puedes entrar en el dll.
Puede aprender OOP, creo. Yo mismo lo aprendí. Y también lo hicieron otros.
Y todavía se puede aprender OOP, creo. Yo mismo lo aprendí. Y así lo han hecho otros.
Así que hay que aprender de los ejemplos adecuados. Pero no hay ninguno en SB. Tomemos el ejemplo de CObject: no proporciona control de tipos, no proporciona trabajo a nivel de interfaz con objetos, pero contiene métodos sin sentido como Save() y Load() que nunca se redefinen en la práctica. Los punteros m_prev y m_next se utilizan en una sola clase CList, pero están presentes como lastre para todas sus clases descendientes. El más útil es el método Comparer(). En realidad, se anula la mayoría de las veces. Pero en el buen sentido, Comparer() es una interfaz, no debería ser definida en el CObject, sino como una clase separada.
Aparentemente static y const (esto no es OOP) no son necesarios.
En cuanto a la programación orientada a objetos, es muy interesante cómo se vería la siguiente función, que tiene una amplia aplicación práctica (nada abstracta), en estilo procedimental...
Obviamente, cualquier OOP puede ser reescrito en estilo procedimental. Pero me interesa la práctica. Así que tomé el diminuto código anterior, en el que también se utiliza la POO al mínimo.
Entonces, ¿cuánto más bonito/más cómodo/más legible/más correcto es el estilo procedimental comparado con la POO en este ejemplo? Bueno, no para hablar durante unas cuantas páginas, pero sólo para comparar el código fuente corto procedural vs OOP. Pido a los opositores de OOP que muestren una clase magistral. No se trata de la temida MT5, sino de la vieja MT4.
¿Cómo se aprende a programar de la misma manera? :) se ve muy bien.
O tal vez necesites cambiar tu mentalidad.
por ejemplo, no sabía que las estructuras se pueden utilizar casi de la misma manera que las clases, con un constructor
por ejemplo, no sabía que las estructuras se pueden utilizar casi de la misma manera que las clases, con un constructor
¿qué moldes se pueden aprender a programar exactamente igual? :) se ve muy bien
o tal vez también necesites cambiar tu mentalidad.
por ejemplo, no sabía que las estructuras se pueden utilizar casi como clases, con un constructor
Y puedo preguntar: ¿qué genialidad ves en el código de fxsaber? ¿Quizás son los efectos secundarios de IsChange los que te han cautivado, o la idea de que el estado del sistema debe ser duplicado a nivel de usuario?
Puedo preguntar: ¿qué genialidad ves en los códigos de fxsaber? ¿Quizás son los efectos secundarios de IsChange los que te fascinan, o la idea de que el estado del sistema debe ser duplicado a nivel de usuario?
Probablemente porque apenas entiendo este código :)
Lo siento, soy un programador aficionado... Sólo estoy familiarizado con la POO a un nivel básico
En C++, la clase y la estructura son las mismas, sólo algunos valores predeterminados son diferentes.
Qué bien, no lo sabía... Supongo que tengo que aprender mejor los profesionales.
Así que hay que aprender de los ejemplos adecuados. Y no hay ninguno en SB. Tomemos el ejemplo de CObject: no proporciona control de tipos, no proporciona trabajo a nivel de interfaz con los objetos, pero contiene métodos sin sentido como Save() y Load(), que nunca se sobrescriben en la práctica. Los punteros m_prev y m_next se utilizan en una sola clase CList, pero están presentes como lastre para todas sus clases descendientes. El más útil es el método Comparer(). En realidad, se anula la mayoría de las veces. Pero en el buen sentido, Comparer() es una interfaz, no debería ser definida en el CObject, sino como una clase separada.