Une question pour les experts de la POO. - page 41

Nouveau commentaire
 
Vladimir Simakov:
Merde. Comment voulez-vous créer un délégué mql ? Juste pour s'amuser, dans le but d'augmenter le BSD.

analogique ne peut pas, l'a fait, vérifié dans MT4 fonctionne jusqu'à présent, mais dans MT5 ne fonctionne plus

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:

analogique ne peut pas, l'a fait, vérifié dans MT4 fonctionne jusqu'à présent, mais dans MT5 ne fonctionne plus

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 différence fondamentale avec le c# est cette ligne :arrPTR[0]=f1 ;

Cela devrait ressembler à quelque chose comme ceci :arrPTR[0]=new tralala(f1) ;

Ou quelque chose comme ça. Ce que je ne comprends pas, c'est comment quelqu'un pourrait vouloir faire ça ? Et de parler de l'adéquation de la pensée de quelqu'un d'autre.
 
Dmitry Fedoseev:

La différence fondamentale avec le c# est que cette ligne :arrPTR[0]=f1 ;

Cela devrait ressembler à quelque chose comme ceci :arrPTR[0]=new tralala(f1) ;

Ou quelque chose comme ça. C'est ce que je ne comprends pas - comment peut-on arriver à vouloir une telle chose ? Et de parler de l'adéquation de la pensée de quelqu'un d'autre.

Dans Sharpe, le concept est le suivant : "prenez la farce de tous les langages existants" + ajoutez la magie sous la forme d'une POO pure et obligatoire dans tous les cas - vous obtenez n'importe quelle solution jusqu'à

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


et après avoir vu ce code, un programmeur C++ commence à y chercher des significations cachées..... mais ça ne sert à rien ! - le seul but est de rassembler tous les non-programmeurs sous le C# imho ))))

 

Les raisons pour lesquelles l'héritage sans restriction conduit à la "dégénérescence" des objets sont trouvées.

EXPLICATION :

1) Nous déclarons une classe de base (abstraite) A.

2. nous construisons une longue chaîne d'héritage à partir de celui-ci. À cette fin, nous créons 10 héritiers de A et 10 descendants de chacun d'eux. Nous avons 10 chaînes d'héritage directes, 10 classes dans chacune.

3. Chaque classe possède 10 propriétés et 10 méthodes uniques. En raison de leur caractère unique, les propriétés et les méthodes sont encapsulées en douceur dans des classes et une hiérarchie claire représentant la structure "élégante" de l'objet de base est construite sur celles-ci.

4. Mais voilà, les propriétés uniques s'épuisent. De nouveaux "objets" apparaissent - "nés" par le croisement de propriétés et de méthodes de différentes classes et de différentes chaînes. Ils n'ont pas de chaîne d'héritage directe de A, mais héritent de leurs propriétés à travers de nombreuses chaînes menant à l'objet de base.

En même temps, héritant leurs propriétés des objets "uniques", les objets "mixtes" n'héritent que de quelques propriétés et méthodes de ces derniers, laissant les autres non réclamées. Ils héritent de nombreuses classes, mais ne devraient prendre qu'une partie de leur matériel "hérité", laissant le reste intact. MAIS CE N'EST PAS POSSIBLE. En accédant à leurs classes, ils héritent de tout ce qui est disponible.

En d'autres termes, leur héritage n'est pas clair. En accédant à leurs "parents", ces objets acquièrent des propriétés et des méthodes dont ils n'ont pas besoin. Et il n'y a aucun moyen d'éviter ces "superfluités".

Cela signifie que l'héritage cesse de fonctionner correctement lorsqu'il y a un grand nombre de descendants. Les objets "dégénèrent" en raison de l'ensemble des "parents" et de la généralisation de la diversité excessive du "matériel hérité". Les objets cessent d'être conceptuellement cohérents.


 
Nah, ça ne peut pas arriver. Quelque part autour du niveau 6-8 de l'héritage, une mutation se produit et un soulèvement des machines se produit.
 
Реter Konow:

Les raisons pour lesquelles l'héritage sans restriction conduit à la "dégénérescence" des objets sont trouvées.

EXPLICATION :

1) Nous déclarons une classe de base (abstraite) A.

2. nous construisons une longue chaîne d'héritage à partir de celui-ci. À cette fin, nous créons 10 héritiers de A et 10 descendants de chacun d'eux. Nous avons 10 chaînes d'héritage directes, 10 classes dans chacune.

3. Chaque classe possède 10 propriétés et 10 méthodes uniques. En raison de leur caractère unique, les propriétés et les méthodes sont encapsulées en douceur dans des classes et une hiérarchie claire représentant la structure "élégante" de l'objet de base est construite sur celles-ci.

4. Mais voilà, les propriétés uniques s'épuisent. De nouveaux "objets" apparaissent - "nés" par le croisement de propriétés et de méthodes de différentes classes et de différentes chaînes. Ils n'ont pas de chaîne d'héritage directe de A, mais héritent de leurs propriétés à travers de nombreuses chaînes menant à l'objet de base.

En même temps, héritant leurs propriétés des objets "uniques", les objets "mixtes" n'héritent que de quelques propriétés et méthodes de ces derniers, laissant les autres non réclamées. Ils héritent de nombreuses classes, mais ne devraient prendre qu'une partie de leur matériel "hérité", laissant le reste intact. MAIS CE N'EST PAS POSSIBLE. En accédant à leurs classes, ils héritent de tout ce qui est disponible.

En d'autres termes, leur héritage n'est pas clair. En accédant à leurs "parents", ces objets acquièrent des propriétés et des méthodes dont ils n'ont pas besoin. Et il n'y a aucun moyen d'éviter ces "superfluités".

Cela signifie que l'héritage cesse de fonctionner correctement lorsqu'il y a un grand nombre de descendants. Les objets "dégénèrent" en raison de l'ensemble des "parents" et de la généralisation de la diversité excessive du "matériel hérité". Les objets cessent d'être conceptuellement cohérents.


Donc - le mauvais concept est construit.
Pourquoi hériter d'une carrosserie de voiture et d'un portrait à partir d'un objet "frame" ?
 
Artyom Trishkin:
Donc - le mauvais concept est construit.
Pourquoi hériter la carrosserie et le portrait de la voiture de l'objet "frame" ?

Dans le domaine des petites tâches, une énorme hiérarchie d'héritage n'est pas nécessaire. Mais, la hiérarchie de la base de connaissances de l'IA est presque illimitée. J'en suis arrivé à la conclusion que la hiérarchie des objets est commode, pratique et efficace jusqu'à certaines limites, après quoi l'héritage "multiple" commence, conduisant à la "dégénérescence" des générations d'objets. Les nouveaux objets sont retirés de la base et leurs propriétés sont "secondaires", car elles sont recueillies auprès d'autres objets. Au cours du processus de "collecte" des propriétés, les nouveaux objets se chargent de "matériel hérité" supplémentaire, qui est "calé" dans leur fonctionnement.

Je ne sais pas comment résoudre ce problème.

 

au cas où quelqu'un le lirait,https://tproger.ru/translations/oop-principles-cheatsheet/

mais j'en doute, ce n'est pas le rôle des bourgeois de lire ce qu'ils écrivent.

 
Igor Makanu:

au cas où quelqu'un le lirait,https://tproger.ru/translations/oop-principles-cheatsheet/

mais j'en doute, ce n'est pas le rôle des bourgeois de lire ce qu'ils écrivent.

L'article parle d'héritage. Lisez-le.

"L'héritage est la capacité d'un objet à se baser sur les propriétés d'un autre."

Mais que se passe-t-il si vous avez un objet de 102ème génération qui peut hériter UNIQUEMENT de plusieurs objets au lieu d'un seul ? Il acquiert des propriétés et des méthodes supplémentaires en fonction du nombre de ses "parents".

 
Реter Konow:

Dans le domaine des petites tâches, une énorme hiérarchie d'héritage n'est pas nécessaire. Mais, la hiérarchie de la base de connaissances de l'IA est presque illimitée. Je suis arrivé à la conclusion que la hiérarchie des objets est commode, pratique et efficace jusqu'à certaines limites, après quoi l'héritage "multiple" commence, conduisant à la "dégénérescence" des générations d'objets. Les nouveaux objets sont retirés de la base et leurs propriétés sont "secondaires", car elles sont recueillies auprès d'autres objets. Au cours du processus de "récolte" des propriétés, les nouveaux objets se chargent de "matériel hérité" supplémentaire qui est "calé" dans leur fonctionnement.

Je ne sais pas comment résoudre ce problème.

Classification claire. Si nous constatons que plusieurs objets ont les mêmes propriétés, il est logique de décrire ces propriétés dans un seul objet parent.
Si un objet enfant remplace une propriété de l'objet parent portant le même nom, cette propriété doit être virtuelle.
1...343536373839404142434445464748...55
Nouveau commentaire