Citation : Freedom

std::vector<obj*> est un fournisseur préféré potentiel de la méthode ~obj() en tant que classe d'une variable de obj, en tant que tel (et par la loi de Demeter), je peus utiliser son protocole, en particulier le message erase(), begin() et end().

Citation : alexisdm

Citation : Freedom

std::vector<obj*> est un fournisseur préféré potentiel de la méthode ~obj() en tant que classe d'une variable de obj, en tant que tel (et par la loi de Demeter), je peus utiliser son protocole, en particulier le message erase(), begin() et end().

Le problème n'est pas que tu puisses ou non utiliser le vector<obj*> et ses méthodes dans obj, mais que tu puisses accéder au vector de parent à partir de this. En gros, tu peux jouer avec parent, mais pas avec les jouets de parent

Il y a aussi un principe de simplification, et parent->collector->erase c'est compliqué, même si tu le décomposes sur plusieurs lignes. Alors que parent->removeChild avec removeChild qui fait collector->erase c'est simple. Avec le principe KISS tu devrais également faire une méthode séparée pour effacer tous les enfants, même si elle reste private ou protected.
En plus, il y a des chances que tu ais besoin par la suite d'une méthode removeChild en dehors du destructeur (pas YAGNI donc). Et garder les 2 codes enfreindrait la règle DRY

Citation : Freedom

Je t'ai fait une demonstration formelle de la validité de mon code par rapport à LoD, elle est pas contestable en disant "tu peut jouer avec parent" qui est une vulagisation de LoD. (quand je dis je peus, ce n'est pas au sens technique, mais bien au sens de la validité de l'architecture du code). (Lis le lien que j'ai donné si tu as des doutes sur ma démonstration et les termes que j'ai utilisé)

Citation : alexisdm

Citation : Freedom

Je t'ai fait une demonstration formelle de la validité de mon code par rapport à LoD, elle est pas contestable en disant "tu peut jouer avec parent" qui est une vulagisation de LoD. (quand je dis je peus, ce n'est pas au sens technique, mais bien au sens de la validité de l'architecture du code). (Lis le lien que j'ai donné si tu as des doutes sur ma démonstration et les termes que j'ai utilisé)

Ce lien n'a qu'une définition incomplète, si tu lis le papier d'origine tu verras que ça s'applique aussi aux objets et pas juste aux classes.

Citation : LoD - Fin de la première section

So far we discussed the class version of the Law of Demeter which can be
enforced at compile-time. The price we pay for compile-time enforceability
is that some programs which violate the ``spirit'' of the Law will pass
the test or that some programs which follow
the ``spirit'' of the Law will be rejected.
Therefore we present now the object version of the Law which expresses
the spirit of the Law and which serves as a conceptual guideline to be
approximated in programming.

Citation : Freedom

Je viens relire le papier, et en effet il y a un version objet, mais le papier précise clairement que celle-ci sert de "guide" pour la verification de la loi, car la version classe est plus difficile à vérifier (le papier parle de verification à la compilation), la version exact étant bien celle avec les classes (il y a même une seconde distinction au sein de cette définition). (Le lien est donc parfaitement complet)

Citation : LoD

The object version of the Law expresses what we really want, but unfortunately it is hard to enforce at compile-time.

Citation : alexisdm

possible d'imposer à la compilation (="which can be enforced at compile-time").
A la fin la partie suivant, il est indiqué plus clairement:

Citation : LoD

The object version of the Law expresses what we really want, but unfortunately it is hard to enforce at compile-time.

Soit: "La version objet de la Loi exprime ce que nous voulons réellement, mais malheureusement, il est difficile de l'imposer à la compilation".

Citation : LoD

the object version [...] which serves as a conceptual guideline to be approximated in programming.

Citation : Freedom

Citation : alexisdm

<citation nom="LoD">
the object version [...] which serves as a conceptual guideline to be approximated in programming.

Bonjour,

Je vais surement me mettre tous le monde a dos (ou pas) car je suis vais être partiellement d'accord avec tous le monde.

Je dis pas avoir la réponse, mais je vais exposer mon avis sur la question.

Pour moi il n'y a aucune obligation a utiliser des pointeurs avec des QObject, sa dépend comment on les utilise (et certains ne laissent pas trop le choix)

Oui Qt a son propre mécanisme de suppression de ses enfants, mais il n'est actif que si on donne un parent a la création de l'objet.

Si on reprends ce très bon exemple :

#include <QObject>
 
int main()
{
   QObject enfant;
   QObject parent;
   enfant.setParent(&parent);
    
}

il suffit de faire ça :

#include <QObject>
 
int main()
{
   QObject enfant;
   QObject parent;
    
}

#include <QObject>
 
int main()
{
   QObject* enfant = new QObject();
   QObject* parent = new QObject();
   enfant = new QObject();
}

MyQObject::MyQObject(QObject parent = nullptr) : QObject(parent)
{

}

Et on l'appelle comme ça par exemple :

MyQObject(this);

Mais si on oublie de fournir un QObject parent ? Ou si dans le constructeur on oublie d'appeler le constructeur parent (en général QObject) ?

Et bien la le mécanisme de suppression ne fonctionne plus. 

Dans la mesure ou il n'est pas absolument nécessaire et en plus pas forcément maitrisé par tous le monde et dur de s'assurer qu'il soit correctement appliqué. Je préfère avoir pour règle qu'il ne soit pas utiliser sauf si nécessaire.

Les cas de nécessité sont assez rare.

Soit parce que vous avez besoin de créer l'objet dynamiquement et qu'en suite vous ne le manipulerez plus du tout (donc a quoi bon le stocker dans un attribut ?).

Ou Alors car vous utilisez un autre dérivé QObject qui a besoin de son parent pour fonctionner (QState il me semble par exemple). 

Et quand vous utilisez le mécanisme QT, ne surtout pas utiliser des smart pointer, ils partageront la responsabilité de la vie du pointeur avec le mécanisme QT et cela fera forcément des étincelles (déjà vu du code comme ça qui plantait systématiquement a la fermeture de l'appli). J'ai enlevé les smart pointer et les pointeurs tout court et l'utilisation des parents/enfants de Qt. Le besoin d'utiliser des pointeurs n'existaient pas, le dev avait cru bien faire en voyant sur internet qu'on utilise des allocations dynamique pour QT, cumulé a l'autre conseil d'utiliser des smartpointer pour chaque allocation dynamique.

Séparément les deux conseils fonctionnent bien, mais une fois cumulé non. Donc je préfère conseiller d'utiliser les pointeurs que si absolument nécessaire, et quand c'est le cas de bien maitriser le cycle de vie de son instance (soit via des smart pointer, soit via le mécanisme Qt, soit ...).

Voila pour mon humble avis sur la question.

> Voila pour mon humble avis sur la question.

en réponse au dernier message qui était de 2010.

Surtout que ca était dit par Freedom que les pointeurs sont pas obligatoires. Et pleins de code d'exemple donnés n'utilisent pas de pointeurs.

Quand a la phase "Les cas de nécessité sont assez rare", je ne suis pas trop d'accord. Il arrive tres souvent qu'on n'a pas le choix avec Qt. Par exemple, dans les codes donnés, on utilise des fonctions comme "setCentralWidget", "setLayout" et "addWidget", qui ajoutent le parent. Et les 2 premiers codes donnés en exemple ne peuvent pas être fait sans pointeur. Plus généralement, quand on écrit une classe QWidget qui contient des membres QWidget, on est souvent obligé d'utiliser des pointeurs (ce qui arrive souvent)

Bonjour,

Le message qui suit est une réponse automatique activée par un membre de l'équipe. Les réponses automatiques leur permettent d'éviter d'avoir à répéter de nombreuses fois la même chose, ce qui leur fait gagner du temps et leur permet de s'occuper des sujets qui méritent plus d'attention.
Nous sommes néanmoins ouverts et si vous avez une question ou une remarque, n'hésitez pas à contacter la personne en question par Message Privé.
Pour plus d'informations, nous vous invitons à lire les règles générales du forum

Déterrage

Citation des règles générales du forum :

Avant de poster un message, vérifiez la date du sujet dans lequel vous comptiez intervenir.

Si le dernier message sur le sujet date de plus de deux mois, mieux vaut ne pas répondre.
En effet, le déterrage d'un sujet nuit au bon fonctionnement du forum, et l'informatique pouvant grandement changer en quelques mois il n'est donc que rarement pertinent de déterrer un vieux sujet.

Au lieu de déterrer un sujet il est préférable :

• soit de contacter directement le membre voulu par messagerie privée en cliquant sur son pseudonyme pour accéder à sa page profil, puis sur le lien "Ecrire un message"
• soit de créer un nouveau sujet décrivant votre propre contexte
• ne pas répondre à un déterrage et le signaler à la modération

Je ferme ce sujet. En cas de désaccord, me contacter par MP.