Une question pour les experts de la POO. - page 42
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Classification claire. Si nous voyons 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.
Que faire si l'objet hérite de propriétés et de méthodes de différentes classes ?
Si nous avons affaire à une structure de données en expansion et en reconstruction dynamique (base de connaissances), nous devons utiliser le "matériel hérité" d'objets déjà préparés pour en créer de nouveaux. Dans ce cas, les objets seront synthétisés par héritage multiple, en récupérant du matériel hérité supplémentaire. Et donc, ne fonctionnera pas correctement. C'est-à-dire que nous arriverons à des objets dégénérés dès que l'héritage multiple commencera. C'est le problème...
Que se passe-t-il si un objet hérite de propriétés et de méthodes de différentes classes ?
Si nous avons affaire à une structure de données en expansion et en reconstruction dynamique (base de connaissances), nous devons utiliser le "matériel hérité" d'objets déjà préparés pour en créer de nouveaux. Dans ce cas, les objets seront synthétisés par héritage multiple, en récupérant du matériel hérité supplémentaire. Et donc, ne fonctionnera pas correctement. C'est-à-dire que nous arriverons à des objets dégénérés dès que l'héritage multiple commencera. C'est le problème...
La boîte à outils correspondante est présentée. Personne n'en a besoin, sauf l'auteur.
Et il est également nécessaire d'en avoir un. Mais personne n'en aura besoin non plus.
Même situation pour les KB, les articles, etc.
Les développeurs ont introduit des caractères, des services, des ticks, des caches, des pips, .... personnalisés. Je suis surpris qu'ils l'aient fait, car il n'y a que quelques personnes, voire aucune, qui en ont besoin.
Prenons le nouveau mode pips du testeur. Qui en a besoin ? -Personne en fait ! Il est né de la vision d'une importante optimisation algorithmique du testeur de la part de ses développeurs. Qui a compris son utilité ? -Personne ! Et ainsi en toute chose.
Maintenant, le Testeur est modifié de manière significative. Mais ces modifications ne sont d'aucune utilité pour personne. Eh bien, il y a des geeks qui vont l'apprécier. Dans sa forme actuelle, MT5-Tester est plus cool que tous ses concurrents. Mais pour une raison quelconque, ils veulent le rendre encore plus cool. Personne n'est en mesure d'évaluer ses caractéristiques actuelles, sans parler de celles à venir. Les développeurs sont plusieurs têtes au-dessus de leurs utilisateurs. Et il est clair que la motivation des changements apportés au Testeur n'est pas la monétisation (elle ne peut tout simplement pas l'être, si personne ne comprend), mais un désir interne de faire quelque chose d'inédit.
Dans le nouvel objet, n'utilisez pas les propriétés des parents "restants". Je vois cependant un certain malentendu avec vous. Pourquoi "donner naissance" à un objet à partir d'un objet dont les propriétés ne sont pas nécessaires ?
Nécessaire, mais pas complètement. Le nouvel objet utilise 3 propriétés de la classe A, 5 propriétés de la classe B, et 3 méthodes, de trois autres classes.
Que doit-il faire avec le reste des propriétés de ces classes ? Comment les empêcher de le faire ?
Nécessaire, mais pas complètement. Le nouvel objet utilise 3 propriétés de la classe A, 5 propriétés de la classe B, et 3 méthodes, de trois autres classes.
Que doit-il faire avec le reste des propriétés de ces classes ? Comment les empêcher de le faire ?
Si un nouvel objet a besoin d'un cœur, il n'a pas besoin d'hériter d'un cœur. Le cœur doit être intégré au nouvel objet, comme un membre.
Hériter si le nouvel objet est un objet ancêtre. Et utiliser l'inclusion si le nouvel objet est AVEC l'autre.
Emballez 3 propriétés de la classe A dans un objet. En hériter. Ou vous pouvez ne pas hériter, mais faire d'un objet avec trois propriétés une propriété de l'objet requis.
Trois propriétés à combiner dans un objet et en faire une propriété d'un nouvel objet ? C'est une chose à laquelle il faut penser...
Mais l'héritage à travers de nombreuses longues chaînes génère des problèmes similaires à chaque étape. Plus les chaînes d'héritage sont longues et diverses, plus les propriétés et les méthodes des dernières générations d'objets seront "mélangées" et plus il sera difficile de dériver leur chaîne individuelle vers l'objet de base.
S'il n'est pas hérité - il n'y aura pas d'accès à l'objet de base. S'ils sont hérités, la "filiation" multiple des objets empêche la traçabilité de leur chaîne directe jusqu'à l'objet de base.
Il devient de plus en plus difficile d'isoler leurs propres propriétés et méthodes des autres classes.
Trois propriétés à combiner dans un objet et en faire une propriété d'un nouvel objet ? C'est une chose à laquelle il faut penser...
Mais l'héritage à travers de nombreuses longues chaînes génère des problèmes similaires à chaque étape. Plus les chaînes d'héritage sont longues et diverses, plus les propriétés et les méthodes des dernières générations d'objets seront "mélangées" et plus il sera difficile de dériver leur chaîne individuelle vers l'objet de base.
S'il n'est pas hérité - il n'y aura pas d'accès à l'objet de base. S'ils sont hérités, la "filiation" multiple des objets empêche la traçabilité de leur chaîne directe jusqu'à l'objet de base.
Il devient de plus en plus difficile d'extraire leurs propres propriétés et méthodes des autres classes.
Peter, je vous recommande vivement
https://en.wikipedia.org/wiki/Code_Complete
Si le cœur est nécessaire dans le nouvel objet, il n'est pas nécessaire d'hériter du cœur. Le cœur doit faire partie du nouvel objet, comme un membre.
Hériter si le nouvel objet EST l'objet ancêtre. Et utiliser l'inclusion si le nouvel objet en CONTIENT un autre.
Trois propriétés à combiner dans un objet et en faire une propriété d'un nouvel objet ? C'est une chose à laquelle il faut penser...
Mais l'héritage à travers de nombreuses longues chaînes génère des problèmes similaires à chaque étape. Plus les chaînes d'héritage sont longues et diverses, plus les propriétés et les méthodes des dernières générations d'objets seront "mélangées" et plus il sera difficile de dériver leur chaîne individuelle vers l'objet de base.
S'il n'est pas hérité - il n'y aura pas d'accès à l'objet de base. S'ils sont hérités, la "filiation" multiple des objets empêche la traçabilité de leur chaîne directe jusqu'à l'objet de base.
Il devient de plus en plus difficile d'isoler leurs propres propriétés et méthodes des autres classes.