OLP. Problèmes d'application - page 10

 

Interesting:

La méthode proposée par Alexander(AlexSTAL) aurait pu résoudre le problème (ne tenons pas compte de sa nature problématique certaine).

Whoa, whoa, whoa, whoa !

Je ne l'ai pas suggéré, j'ai dit que c'était une possibilité.

Et quel est ton problème, je ne peux pas comprendre ?

Vous devez être en train de discuter d'un exemple où la moitié de la logique est manquante et l'autre moitié est fausse (vestige des débuts de la POO) ?

 
AlexSTAL:

Whoa, whoa, whoa, whoa !

Je ne l'ai pas suggéré, j'ai dit que c'était une possibilité.

Et quel est ton problème, je ne peux pas comprendre ?

Disons que vous devez placer différents objets dans un tableau.

En même temps, toutes les propriétés de ces objets doivent être stockées dans le même tableau + il doit y avoir un accès à tous les événements et méthodes.

La possibilité que vous offrez (l'implémentation peut être différente) permet, d'après ce que je comprends, d'accéder à la fonctionnalité des objets (événements et méthodes).

Mais le stockage de données dans un tableau avec un type ancêtre a peu de chances de fonctionner (si l'on tient compte du fait que ces données n'ont pas été déclarées dans l'ancêtre).


Laissez-moi clarifier ma pensée.

Si nous nous arrêtons à cet exemple particulier, alors :

1. Disons que nous pouvons créer un tableau qui stockera le type d'objet, la position en X, la position en Y ;

2. Nous pourrions essayer d'identifier un objet unique par son pointeur (bien que lorsque l'on travaille avec un objet, le pointeur puisse ne pas être utilisé, il serait alors souhaitable d'avoir quelque chose comme un handle) ;

Une question stupide (je ne vois pas d'autre solution), pourquoi utiliser un pointeur comme poignée (créer une propriété dans l'ancêtre et la remplir dans le constructeur) ?

Nous n'avons pas la possibilité de stocker les propriétés descendantes dans un tableau (seulement celles qui ne sont pas définies dans l'ancêtre). Par exemple, pour autant que je sache, nous ne pouvons pas stocker le rayon d'un cercle ou le côté d'un carré dans un tableau.

 
Interesting:

3. nous n'avons pas la possibilité de stocker les propriétés descendantes dans le tableau (seulement celles qui ne sont pas frappées dans l'ancêtre). Par exemple, d'après ce que je comprends, on ne peut pas stocker le rayon d'un cercle ou le côté d'un carré dans un tableau.

Pourquoi ça ne marcherait pas... Vous ne les adressez pas directement, mais utilisez votre fonction "GetValue" avec le paramètre "radius" (si l'objet est un cercle)... C'est une des possibilités...

Vous fixez une tâche simple et spécifique

 
AlexSTAL:

Pourquoi ça ne marcherait pas... Vous ne les adressez pas directement, mais utilisez votre fonction "GetValue" avec le paramètre "radius" (si l'objet est un cercle)... C'est une des possibilités...

Vous définissez un problème simple et spécifique

La tâche est simple, mais qui peut dire qu'elle est facile à mettre en œuvre ?

La tâche consiste à enregistrer dans un tableau divers objets (descendants de la classe de base) ainsi que leurs données.

Disons-le clairement, qu'avec leurs données !!!

2. GetArea() pour chaque descendant ;

3. Ajoutez les fonctionnalités suivantes :

a. Calculez le périmètre du carré - côté *4 ;

б. Calcul du périmètre d'un cercle - 2πR.

3. Ajoutez des formes supplémentaires à la bibliothèque : rectangle (deux côtés) et triangle.

4. Ajoutez les fonctionnalités suivantes :

a. calculer l'aire d'un rectangle - base à hauteur ;

б. Calculez le périmètre d'un rectangle - somme des côtés *2 ;

в. Calcul de l'aire d'un triangle ;

г. Calcul du périmètre d'un triangle.

5. Identifier chaque objet individuellement (parmi tous les objets et parmi les objets de sa classe).

De préférence avec ou sans pointeurs.

6. calculez le périmètre et l'aire des formes en utilisant uniquement les données stockées dans le tableau.


PS

Il n'est pas permis de transférer un code des descendants vers l'ancêtre (sauf si ce code s'applique à tous les ancêtres).

C'est-à-dire que vous ne pouvez pas, par exemple, transférer un rayon dans un ancêtre, puisqu'un carré, un rectangle et un cercle n'en ont pas.

Une nouvelle fonctionnalité peut être ajoutée à un ancêtre pour autant qu'elle s'applique à tous les descendants.

Nous prenons le code de la remorque comme base.

Когда нужно использовать указатели в MQL5
Когда нужно использовать указатели в MQL5
  • 2010.03.25
  • MetaQuotes Software Corp.
  • www.mql5.com
Все объекты в MQL5 по умолчанию передаются по ссылке, но есть возможность использовать и указатели объектов. При этом есть опасность получить в качестве параметра функции указатель неинициализированного объекта. В этом случае работа программы будет завершена критически с последующей выгрузкой. Автоматически создаваемые объекты как правило такой ошибки не вызывают, и в этом отношении они достаточно безопасны. В этой статье мы попробуем разобраться в чем разница между ссылкой и указателей, когда оправдано использование указателей и как написать безопасный код с использованием указателей.
Dossiers :
Forum-3.mq5  11 kb
 

Dans un seul tableau, j'ai personnellement résolu le problème en ajoutant simplement des variables pour stocker l'aire et le périmètre à l'ancêtre + une fonctionnalité pour y écrire des données.

Dans ce cas, si le résultat de GetArea() et d'autres fonctions de calcul direct est contrôlé.

Je ne semble pas avoir enfreint mes propres règles.

 

J'ai esquissé une façon de mettre en œuvre l'approche que vous décrivez.

Elle n'est pas complète, mais c'est l'approche la plus importante.

Dossiers :
_script.mq5  4 kb
 
AlexSTAL:

J'ai esquissé une façon de mettre en œuvre l'approche que vous décrivez.

Elle n'est pas complète, mais c'est l'approche la plus importante.

L'approche est claire. C'est probablement l'une des meilleures solutions à un problème similaire.

Au moins pour le moment.

 
Interesting:

La tâche est simple, mais qui a dit qu'elle était facile à mettre en œuvre ?

1. La tâche consiste à écrire différents objets (descendants d'une classe de base) avec leurs données dans un tableau.

...
Feuilles de calcul dans MQL5: le problème a déjà été résolu et décrit.
 
Urain:
Les feuilles de calcul dans MQL5 ont déjà résolu et décrit le problème.

Comme c'est bon de pouvoir lire... :)

Ce n'est pas non plus une mauvaise approche, bien que, si j'ai bien compris, ces deux approches soient conçues pour le transfert/la lecture d'un seul paramètre (bien que de types différents).

Mais que faire s'il y a beaucoup de paramètres et qu'il est impossible de les faire rentrer tous dans une classe de base ?

D'après ce que je comprends, l'index du paramètre à passer doit être saisi en plus (on peut aussi créer un tableau avec les paramètres empilés par index dans la classe).

 
Interesting:

Comme c'est bon de pouvoir lire... :)

Ce n'est pas non plus une mauvaise approche, bien que, si j'ai bien compris, ces deux approches soient calculées sur le transfert/la lecture d'un seul paramètre (bien que de types différents).

Et que faire s'il y a beaucoup de paramètres et qu'il est impossible de les inclure tous dans la classe de base ?

D'après ce que j'ai compris, il est possible de saisir un index du paramètre à passer (il est également possible de créer un tableau avec des paramètres empilés par index dans une classe) ?

Je l'ai lu trois fois et je ne comprends toujours pas le sens du message.
Raison: