Una pregunta para los expertos en POO. - página 41

 
Vladimir Simakov:
Mierda. ¿Cómo quieres copiar el delegado en mql? Sólo por diversión, para aumentar el BSD.

analógico no puede, lo hizo, comprobado en MT4 funciona hasta ahora, pero en MT5 ya no funciona

typedef void(*TFuncvoidPTR)(void);
//+------------------------------------------------------------------+
void OnStart()
{  TFuncvoidPTR arrPTR[3];
   arrPTR[0]=f1;
   arrPTR[1]=f2;
   arrPTR[2]=f3;
   for(int i=0; i<3; i++)
      arrPTR[i]();			// ' ) ' - expression expected

}
//_______________________________________________________________________
void f1() { Print("1"); }
void f2() { Print("2"); }
void f3() { Print("3"); }
//+------------------------------------------------------------------+

2019.10.06 16:22:44.202 tst EURUSD,H1: 3

2019.10.06 16:22:44.202 tst EURUSD,H1: 2

2019.10.06 16:22:44.202 tst EURUSD,H1: 1

 
Igor Makanu:

analógico no puede, lo hizo, comprobado en MT4 funciona hasta ahora, pero en MT5 ya no funciona

2019.10.06 16:22:44.202 tst EURUSD,H1: 3

2019.10.06 16:22:44.202 tst EURUSD,H1: 2

2019.10.06 16:22:44.202 tst EURUSD,H1: 1

La diferencia fundamental con c# es esta línea:arrPTR[0]=f1;

Debería ser algo así:arrPTR[0]=nueva tralala(f1);

O algo así. Lo que no entiendo es, ¿cómo puede alguien querer hacer eso? Y para hablar de la idoneidad del pensamiento de otra persona.
 
Dmitry Fedoseev:

La diferencia fundamental con c# es que esta línea:arrPTR[0]=f1;

Debería ser algo así:arrPTR[0]=nueva tralala(f1);

O algo así. Eso es lo que no entiendo: ¿cómo se puede llegar a querer algo así? Y para hablar de la idoneidad del pensamiento de otra persona.

En Sharpe, el concepto: "tomar el relleno de todos los lenguajes existentes" + añadir magia en forma de OOP pura y obligatoria en cualquier caso - se obtiene cualquier solución hasta

int a = new int();
char b = new Char();
string c = new string(new char[] { });
string d = String.Empty;
String e = String.Empty;


y después de ver este código un programador de C++ empieza a buscar significados ocultos en él.... ¡pero no tiene sentido! - el único punto es reunir a todos los no programadores bajo C# imho ))))

 

Se encuentran las razones por las que la herencia irrestricta conduce a la "degeneración" de los objetos.

EXPLICACIÓN:

1. Declaramos una clase base (abstracta) A.

2. Construimos una larga cadena de herencia a partir de ella. Para ello creamos 10 herederos de A y 10 descendientes de cada uno de ellos. Tenemos 10 cadenas directas de herencia, 10 clases en cada una.

3. Cada clase tiene 10 propiedades y 10 métodos únicos. Debido a su singularidad, las propiedades y los métodos se encapsulan sin problemas en las clases y sobre ellas se construye una clara jerarquía que representa la estructura "elegante" del objeto base.

4. Pero he aquí que las propiedades únicas se agotan. Aparecen nuevos "objetos" - "nacidos" por el cruce de propiedades y métodos de diferentes clases y diferentes cadenas. No tienen una cadena de herencia directa de A, sino que heredan sus propiedades a través de muchas cadenas que llevan al objeto base.

Al mismo tiempo, al heredar sus propiedades de los objetos "únicos", los objetos "mixtos" sólo heredan algunas propiedades y métodos de éstos, dejando otros sin reclamar. Heredan muchas clases, pero sólo deben tomar parte de su material "heredado", dejando el resto sin tocar. PERO ESTO NO ES POSIBLE. Al acceder a sus clases, heredan lo que esté disponible.

En otras palabras, su herencia no está clara. Al acceder a sus "padres", estos objetos adquieren propiedades y métodos que no necesitan. Y no hay manera de evitar estas "superfluidades".

Esto significa que la herencia deja de funcionar correctamente cuando hay un gran número de descendientes. Los objetos "degeneran" por el conjunto de "padres" y la generalización de la excesiva diversidad del "material heredado". Los objetos dejan de ser conceptualmente coherentes.


 
No, eso no puede pasar. En algún punto del nivel 6-8 de la herencia se produce una mutación y se produce un levantamiento de la máquina.
 
Реter Konow:

Se encuentran las razones por las que la herencia irrestricta conduce a la "degeneración" de los objetos.

EXPLICACIÓN:

1. Declaramos una clase base (abstracta) A.

2. construimos una larga cadena de herencia a partir de ella. Para ello creamos 10 herederos de A y 10 descendientes de cada uno de ellos. Tenemos 10 cadenas directas de herencia, 10 clases en cada una.

3. Cada clase tiene 10 propiedades y 10 métodos únicos. Debido a su singularidad, las propiedades y los métodos se encapsulan sin problemas en las clases y sobre ellas se construye una clara jerarquía que representa la estructura "elegante" del objeto base.

4. Pero he aquí que las propiedades únicas se agotan. Aparecen nuevos "objetos" - "nacidos" por el cruce de propiedades y métodos de diferentes clases y diferentes cadenas. No tienen una cadena de herencia directa de A, sino que heredan sus propiedades a través de muchas cadenas que llevan al objeto base.

Al mismo tiempo, al heredar sus propiedades de los objetos "únicos", los objetos "mixtos" sólo heredan algunas propiedades y métodos de éstos, dejando otros sin reclamar. Heredan muchas clases, pero sólo deben tomar parte de su material "heredado", dejando el resto sin tocar. PERO ESTO NO ES POSIBLE. Al acceder a sus clases, heredan lo que esté disponible.

En otras palabras, su herencia no está clara. Al acceder a sus "padres", estos objetos adquieren propiedades y métodos que no necesitan. Y no hay manera de evitar estas "superfluidades".

Esto significa que la herencia deja de funcionar correctamente cuando hay un gran número de descendientes. Los objetos "degeneran" por el conjunto de "padres" y la generalización de la excesiva diversidad del "material heredado". Los objetos dejan de ser conceptualmente coherentes.


Por lo tanto, se construye el concepto equivocado.
¿Por qué heredar una carrocería y un retrato de un objeto "marco"?
 
Artyom Trishkin:
Por lo tanto, se construye el concepto equivocado.
¿Por qué heredar la carrocería y el retrato del objeto "marco"?

En el ámbito de las pequeñas tareas, no se requiere una enorme jerarquía de herencia. Pero, la jerarquía de la base de conocimientos de la IA, es casi ilimitada. He llegado a la conclusión de que la jerarquía de los objetos es conveniente, práctica y eficaz hasta ciertos límites, después de los cuales comienza la herencia "múltiple", que conduce a la "degeneración" de las generaciones de objetos. Los nuevos objetos se eliminan de la base y sus propiedades son "secundarias", porque se recogen de otros objetos. En el proceso de "recogida" de propiedades, los nuevos objetos adquieren un "material heredado" extra, que se "cuela" en su funcionamiento.

No sé cómo resolver este problema.

 

por si alguien lo lee,https://tproger.ru/translations/oop-principles-cheatsheet/

aunque lo dudo, no es tarea de los burgueses leer lo que escriben.

 
Igor Makanu:

por si alguien lo lee,https://tproger.ru/translations/oop-principles-cheatsheet/

aunque lo dudo, no es tarea de los burgueses leer lo que escriben.

El artículo habla de la herencia. Léelo.

"La herencia es la capacidad de un objeto de basarse en las propiedades de otro".

¿Pero qué pasa si tienes un objeto de la generación 102 que puede heredar SOLO de varios objetos en lugar de uno? Adquirirá propiedades y métodos adicionales en proporción al número de sus "padres".

 
Реter Konow:

En el ámbito de las pequeñas tareas, no se requiere una enorme jerarquía de herencia. Pero la jerarquía de la base de conocimientos de la IA es casi ilimitada. Llegué a la conclusión de que la jerarquía de los objetos es conveniente, práctica y eficaz hasta ciertos límites, después de los cuales comienza la herencia "múltiple", que conduce a la "degeneración" de las generaciones de objetos. Los nuevos objetos se alejan de la base y sus propiedades son "secundarias", porque se recogen de otros objetos. En el proceso de "cosecha" de propiedades, los nuevos objetos adquieren un "material heredado" extra que se "cuela" en su funcionamiento.

No estoy seguro de cómo resolver este problema.

Clasificación clara. Si vemos que varios objetos tienen las mismas propiedades, entonces es lógico describir estas propiedades en un objeto padre.
Si un objeto hijo anula una propiedad del objeto padre con el mismo nombre, esa propiedad debe ser virtual.