OOP vs. programación procedimental - página 14
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
¿Puedes darme un ejemplo de estas tareas de tipo único, que es mejor no hacer sin OOP?
Sin OOP puedes resolverlo, pero con OOP es más rápido, te lo dije...
Por ejemplo, un patrón puede contener de 0 a 100 patrones de velas, de 0 a 30 indicadores diferentes y de 1 a 5 señales diferentes en cada uno de ellos... Así, tenemos 1 clase, y podemos establecer con el constructor que la primera instancia contendrá 23 patrones de este tipo y 2 indicadores con 1 señal cada uno... La segunda instancia contendrá otros 12 patrones y otros 8 indicadores... A continuación, establecemos la condición de que ambas instancias deben dar una señal de apertura a no más de 4 barras de distancia entre sí...
Todo esto se hace en 5 segundos si las señales de los patrones y todo lo demás se describe en la clase... Y puede haber tantas combinaciones de todo esto como se quiera, e incluso sin cliente, sólo hay que optimizar todo esto automáticamente en el optimizador y buscar condiciones de entrada favorables... El optimizador puede ampliar el número de instancias y las propiedades de cada una de ellas... bueno, etc. ))
Este no es el argumento principal.
No existe un análogo del polimorfismo en la programación procedimental.
Es curioso que durante toda mi práctica, ya que era un completo novato en la programación y aún lo soy en cierta medida, nunca encontré necesario utilizar el polimorfismo... Ese debe ser mi destino.
(El infierno sabe por qué...))
Sin OOP puedes resolverlo, pero con OOP es más rápido, te lo dije...
Por ejemplo, un patrón puede contener de 0 a 100 patrones de velas, de 0 a 30 indicadores diferentes y de 1 a 5 señales diferentes en cada uno de ellos... Así, tenemos 1 clase, y podemos establecer con el constructor que la primera instancia contendrá 23 patrones de este tipo y 2 indicadores con 1 señal cada uno... La segunda instancia contendrá otros 12 patrones y otros 8 indicadores... A continuación, establecemos la condición de que ambas instancias deben dar una señal de apertura a no más de 4 barras de distancia entre sí...
Todo esto se hace en 5 segundos si las señales de los patrones y todo lo demás se describe en la clase... Y puede haber tantas combinaciones de todo esto como se quiera, e incluso sin cliente, sólo hay que optimizar todo esto automáticamente en el optimizador y buscar condiciones de entrada favorables... El optimizador puede ampliar el número de instancias y las propiedades de cada una de ellas... etc.)
Toda esta debacle del GOP es a escala universal.
Después de todo, hay que tener mucho talento para impulsar algo así en todo el mundo.
Y nada detiene a los apologistas.
Si tomas los apologistas locales. Ante sus narices está el manual del lenguaje MQL. Veamos las secciones. Sólo tres secciones están dedicadas a los datos y todo el resto describe las ACCIONES: programa, operaciones de matriz, conversiones de datos.....
Será que se trata de un lenguaje μl que no se ajusta a las "ideas de vanguardia"?
Tomemos un sistema de software mucho más grande: R.
Contiene más de 10.000 paquetes, cada uno de los cuales contiene funciones, que son acciones, no objetos.
Tal y como yo lo veo, todos estos apologistas de la OOP de origen local y mundial no entienden nada de programación, a saber: el valor (semántico) de cualquier dato es una función, una acción que procesa ese dato. Escribieron int. El significado de estos caracteres está determinado por un conjunto de comandos del procesador, que sabe cómo realizar la ACCIÓN con esta variable.
A continuación, pasemos a las clases.
Si tomamos R, para lo cual las clases son parte del lenguaje.
Una función introduce un objeto de una clase y la salida es un objeto de otra clase. El significado de los campos de entrada-salida está determinado únicamente por la función que lo maneja todo. Y si la función no acepta una determinada clase, esta clase no sirve para esta función. Por eso, la documentación de cada paquete es exactamente la misma que la de µl: se enumeran las acciones y las funciones. Y los enlaces entre funciones de un paquete, o con funciones de otro paquete, se determinan por el nombre de la clase con la que trabaja la función concreta.
Otra vez. En R, los objetos pueden tener una complejidad arbitraria y, de hecho, pueden ser muy complejos. Pero el valor de cada campo de un objeto de una determinada clase está totalmente determinado por la función que genera ese objeto.
Esto es especialmente obvio para aquellos que escribieron compiladores (y yo lo hice). Se escribe alguna secuencia de código. ¿Qué hace este código? ¿Qué significa este código? El significado del texto en el lenguaje fuente de cualquier lenguaje de programación estará determinado por el código ejecutable que crea el compilador, que finalmente será percibido por el procesador. El compilador de un idioma encontrará el significado de las líneas escritas, pero el de otro no, es decir, las líneas escritas no tienen significado para este otro idioma.
Por lo tanto: el significado de un objeto es siempre una función, una acción que es capaz de tomar datos de entrada como guía para la acción, y generar en la salida una determinada lista de campos, cuyo valor está determinado únicamente por esta función.
Konov trató de explicar más arriba que hay que pasar de las ACCIONES. Es necesario tratar las acciones, y los objetos que conectan estas acciones se tratarán más tarde, cuando se definan las acciones. Pero la claridad y la eficacia del código provienen exclusivamente de lo bien que hemos conseguido organizar toda la jerarquía de ACCIONES y su interacción.
Los defensores de la POO dicen: creemos objetos. Pero, ¿qué sentido tienen los campos de los objetos si no definimos acciones sobre estos campos?
¿Cómo se implementa el patrón que contiene los patrones? ¿Es una función, una matriz o algo más? ¿Cómo se escriben los patrones?
Sí, normalmente se describen, pero no se trata de eso...
Otro ejemplo... una clase es como una biblioteca con libros, y un ejemplar es un carrito... En un carrito puedes poner los libros que elijas de la biblioteca... ... y buscar algo más rentable...) La biblioteca y 1 carro se pueden hacer sin OOP, y cuando hablamos de un gran número de carros, es mejor hacerlo con OOP...
Este es el único argumento a favor de la POO en el desarrollo que ahora acepto.
No deberías aceptarlo.
El último equipo en el que trabajé tenía unas 300 personas. La carga de trabajo total para todo el proyecto del programa es de unos 1.500 años-hombre. La organización de un equipo de este tipo para trabajar juntos no ayudará a ningún POA. Para ello, había otros enfoques, que implicaban el desglose de todo el problema en etapas y la regulación cuidadosa de todo y todos en cada paso. Había GOSTs que lo describían. En el ámbito de la programación, fue el USSD (Sistema Unificado de Documentación de Programas). En cuanto a la intensidad de la mano de obra, la codificación en sí misma supuso un 20% de la mano de obra.
No escuches a los defensores de la OOP. Vas por buen camino. Incluso el hecho de no fusionar dos variables en una sola estructura - no se puede ver el beneficio de tal fusión
Otro ejemplo muy sencillo, que está en la superficie... Generador de EA en el MetaEditor... Cualquiera, incluso si no sabe programar, puede crear un EA con un gran número de indicadores y condiciones en 10 segundos )))) Y todo esto es OOP )))
No hablemos del generador, porque he decidido no jurar durante 2 meses )))
Compañeros desarrolladores de MQ, les tengo mucho respeto. Lo digo en serio.
Y comprendo las razones de la creación de estos constructores. También entiendo por qué todos estos constructores se tiran un pedo en el vacío.
Sí, puede ser visto como una especie de ejemplo para estudiar MQL5, pero de ninguna manera como un punto de partida para un verdadero robot de comercio.
No deberías aceptarlo.
El último equipo en el que trabajé tenía unas 300 personas. La carga de trabajo total para todo el proyecto del programa es de unos 1.500 años-hombre. Organizar un equipo de este tipo para trabajar juntos no ayudará a ninguna OOP. Para ello, había otros enfoques, que implicaban el desglose de todo el problema en etapas y la regulación cuidadosa de todo y todos en cada paso. Había GOSTs que lo describían. En el ámbito de la programación, fue el USSD (Sistema Unificado de Documentación de Programas). En términos de mano de obra, la codificación en sí misma supuso un 20% de la mano de obra.
No escuches a los defensores de la OOP. Vas por buen camino. Incluso el hecho de no fusionar dos variables en una sola estructura no tiene mucho beneficio
San-Sanych, hace poco se puso en contacto conmigo un supuesto progre que incluso consiguió vender algo en el Mercado.
Me dijo que intenté pegar unos programas y me dio un error de compilación, por lo que me envió su pegamento. Prometió pagarme.
He echado un vistazo y estoy harto, 59 errores de compilación.
Muchas variables globales como n,c,m.
Todos en conflicto entre sí.
Y el tipo está seguro de que sólo necesita unos retoques y puede lanzarlo en el Mercado.
...
Según entiendo, todos estos apologistas de la OOP de origen local y global no entienden nada en programación, a saber: el valor (semántico) de cualquier dato es una función, una acción, que procesa este dato. Escribieron int. El significado de estos caracteres está determinado por un conjunto de comandos del procesador, que sabe cómo realizar la ACCIÓN sobre esta variable.
...
en la memoria
No deberías aceptarlo.
El último equipo en el que trabajé tenía unas 300 personas. La carga de trabajo total para todo el proyecto del programa es de unos 1.500 años-hombre. Organizar un equipo de este tipo para trabajar juntos no ayudará a ninguna OOP. Para ello, había otros enfoques, que implicaban el desglose de todo el problema en etapas y la regulación cuidadosa de todo y todos en cada paso. Había GOSTs que lo describían. En el ámbito de la programación, fue el USSD (Sistema Unificado de Documentación de Programas). En cuanto a la intensidad de la mano de obra, la codificación en sí misma supuso un 20% de la mano de obra.
No escuches a los defensores de la OOP. Vas por buen camino. Incluso el hecho de no fusionar dos variables en una estructura no muestra ningún beneficio
Estos programas los escribe ahora una persona en tres días.