OOP vs. programación procedimental - página 39

[Dmitry Fedoseev]

Andrei:

La clase sólo tiene variables internas y no tiene entrada ni salida... ¿Dónde has visto el uso en la programación de un objeto así, que no tiene ningún contacto con el mundo exterior y que hierve en su propio jugo?

¿Por qué discutes sobre algo que no has visto? Se crea un constructor de clase que puede recibir cualquier número de parámetros. Diferentes clases hijas pueden tener conjuntos de parámetros completamente diferentes en sus constructores. Sólo tienes que escribir métodos para establecer los parámetros.

[Dmitry Fedoseev]

СанСаныч Фоменко:

1. esta es la principal respuesta a la necesidad de OOP.

2. es una cuestión de experiencia en equipos. Escribí todo lo que necesitaba. Hace un par de años decidí escribir un poco más: todo se lee, sin problemas.

De vuestras respuestas he entendido una cosa: la POO es un cierto estándar que introduce la disciplina de la programación, introduce la uniformidad y sobre esta base se reducen los errores inicialmente y, sobre todo, los problemas durante la modificación. Pero el mismo resultado se obtuvo con una cuidadosa observancia de los GOST, las fases de desarrollo y la documentación.

¿Cuántas veces tengo que decirte lo mismo? La programación orientada a objetos no es sólo un medio para estructurar el código, sino que también contiene mecanismos que están ausentes en su programación procedimental.

Tal vez sea el caso de que si una persona no ha visto montañas, no entenderá lo que es, aunque se lo digas.

[Dmitry Fedoseev]

Реter Konow:

Personalmente, busco la versatilidad en las soluciones. Esto requiere "empalmar" funciones similares en un solo bloque sin aumentar el tamaño del código. Aumenta la eficiencia del mecanismo y no hay necesidad de sobrecarga y división. Sólo hay que usar un poco el cerebro, eso es todo).

Es decir, había dos funciones de 20 líneas cada una. Ambos realizan acciones similares o resuelven tareas parecidas. Mi objetivo es hacer una función que haga el trabajo de ambas con no más de 20 líneas de código. Así es como creo los bloques.

¿Cuánto tiempo has estado estudiando esta biblioteca tuya?

[Renat Fatkhullin]

Por si acaso, R está escrito en un modo absolutamente asqueroso de "todo en un cubo de basura sin diferenciación de acceso". Un enfoque de la vieja escuela de hace veinte años sin áreas de visibilidad, protección o multisesión. Escribo como si fuera el único. Sí, el proyecto nació bajo una persona por desarrolladores poco profesionales. Hay que reescribirlo desde cero. Al menos una vez.

Tenía la idea de hacer una interfaz normal en R a partir de MQL5, pero después de profundizar en ella decidí inmediatamente no integrarla. El sistema es categóricamente incapaz de proteger los datos y las sesiones.

Hasta que un programador no trabaje en equipos de desarrollo normales con requisitos estrictos (golpeando sus manos durante un par de años como mínimo) no se convertirá en un desarrollador en un sentido normal. Nos agarramos la cabeza el 90% de las veces cuando miramos los trabajos de prueba al considerar los candidatos. Horror total en toda la industria del desarrollo.

Así que, una vez más, los que se oponen a la OOP hacen gala de una especie de bufonada.

Lo siento de nuevo.

[Georgiy Merts]

СанСаныч Фоменко:

¡Vaya!

Me preguntaba: ¿hay alguna otra manera en la programación actual de confundir un problema de nivel de huevo de una manera más fresca?

Acércate a un coche parado en un atasco, mira cómo está colocado y dile al conductor "hay alguna forma de confundir mejor el problema, camina cien metros hacia aquí".

Como muestra mi experiencia, estos "problemas confusos" son mucho más fáciles de entender que los EAs "sin problemas" hechos copiando de una sola plantilla con todas las variables globales.

[Andrei01]

Dmitry Fedoseev:

¿Y por qué especulas aquí sobre algo que no has visto? Se crea un constructor de clase que puede recibir cualquier número de parámetros.

Lee con atención, se trataba de la clase, no del constructor de la clase.

Además, vuelves a sugerir hacer el trabajo de un mono - plantar un jardín en una parcela cuando podemos tener acceso a los parámetros sin hacer NADA en el caso de las variables externas o pasarlas directamente sin ningún dolor de cabeza innecesario con los constructores-destructores y todas las fugas de memoria que conllevan.

[Georgiy Merts]

СанСаныч Фоменко:

MiOnInit() tiene el mismo aspecto - una docena de líneas...

¿Y qué?

Para Reason, en TODOS mis EAs hay diez líneas (si no se cuentan las inclusiones y los comentarios).

#include <MyLib\DebugOrRelease\DebugSupport.mqh>
#include <MyLib\Factories\ForTrade\EURGBP\B1H2C20T2_0001_EPF.mq5>
#include <MyLib\Factories\ForTrade\EURGBP\B2H2C20T4_0001_EPF.mq5>
#include <MyLib\Factories\ForTrade\EURGBP\B3H2C20T2_0001_EPF.mq5>

// Объявляем фабрики частей эксперта.
CB1H2C20T2_0001_EPF epfFact_0;
CB2H2C20T4_0001_EPF epfFact_1;
CB3H2C20T2_0001_EPF epfFact_2;

// Объявляем функцию получения указателя на фабрику.
CEAPartsFactoryT* CEAPartsFactoryT::GetAdvisorsPartsFactory(uint uiFactIdx = 0)
{
   if(uiFactIdx == 0) return(GetPointer(epfFact_0)); 
   if(uiFactIdx == 1) return(GetPointer(epfFact_1)); 
   if(uiFactIdx == 2) return(GetPointer(epfFact_2)); 
   return(NULL); 
};

#include <MyLib\TSTemplate\ExpertAdvisorT.mq5>

En nuestro caso, hay tres TSs completamente diferentes en un EA. Todos funcionan simultáneamente, sin interferir entre sí.

Se pueden añadir TCs adicionales declarando la fábrica apropiada, y añadiendo código que la devuelva en una función.

Pero la verdadera cuestión no es si hay pocas o demasiadas líneas de código. La cuestión es lo fácil que es mantenerlos y modificarlos si es necesario.

SanSanych, ¿puedes averiguar fácilmente el archivo de la tabla proporcionada por Peter? ¿Y modificarlo fácilmente? Bueno, entonces tú, como Peter, no necesitas OOP.

[Georgiy Merts]

Реter Konow:
La POO es un método para separar, envolver y ocultar partes de un mecanismo. El desarrollador debe decidir si esto es necesario o no. No tiene nada que ver con el aumento de la eficiencia del mecanismo en absoluto. Estructura la forma de pensar, sí. Se desconoce si lo estructura correctamente o no. Que sea necesario depende de cada persona, en mi opinión.

Exactamente. Esta es la esencia de la encapsulación.

También hay herencia y polimorfismo.

[Andrei01]

Реter Konow:
La POO es un método para separar, envolver y ocultar partes de un mecanismo. Que esto sea necesario depende de cada persona. imho.

Exactamente, depende del individuo. ¿Por qué un programador, que no sufre de esquizofrenia, ocultaría enérgicamente el acceso a una parte de su propio código que está depurando él mismo? ¿No prefieres atarte las manos tú mismo? :)

[Andrei01]

Renat Fatkhullin:

Hasta que un programador no haya trabajado en equipos de desarrollo normales con requisitos estrictos (golpeado con las manos durante un par de años como mínimo), no se convertirá en un desarrollador en el sentido normal. Nos agarramos la cabeza el 90% de las veces cuando miramos los trabajos de prueba al considerar los candidatos. Horror total en toda la industria del desarrollo.

Me pregunto en qué se manifiesta este "horror".

Puedo suponer que tiene que ver con el uso de la P OO, porque en la programación procedimental se presta la principal atención a la lógica del trabajo del algoritmo en lugar de todo tipo de añadidos externos tipo POO, que pueden construir fácilmente un bosque de cualquier obtusidad.