Discussion :

[lkr22]

Bonjour,

Après recherche sur google je n'ai pas trouvé de réponse à ma question.

J'ai plusieurs projets dans ma solution.

Dans le projet A, j'ai un bouton (QPushButton) que je connecte comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

connect(dialog->pushButtonA, SIGNAL(clicked()),this, SLOT(action()));

Dans le projet B, j'ai un bouton (QPushButton) que je connecte comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

connect(dialog->pushButtonB, SIGNAL(clicked()),this, SLOT(action()));

La méthode "action()" se situe dans le projet C.

Ma méthode "action()" est constitué comme ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
.... action(....)
{
if(pushButtonA cliqué)
{
...
}
else (pushButtonB cliqué)
{
...
}
 
partie de code commune aux 2 boutons
 
}

Ma question est : Que mettre dans la parenthèse du if afin de rentrer dans la boucle lorsqu'on a cliqué sur le bouton ?


Merci

[koala01]

Salut,

Si tu as deux boutons qui nécessitent des actions différentes, tu dois avoir deux slots différents.

Maintenant, si les deux actions sont "complexes", et que "certaines parties" de ces actions sont identiques, tu peux toujours créer des fonctions membres (privées) qui prendront ces parties communes en charge, ce qui te donnerait un code proche de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
class MyClass: public QMainWindow{
    Q_OBJECT
public:
    MyClass(QWidget * parent = nullptr);
private:
/* les slots */
    void slotActionA();
    void slotActionB();
/* la partie commune à A et à B */
    void commonPart();
/* les deux dialogues */
    MyDialogA * dialogA;
    MyDialogB * dialogB;
};

avec le code, pour le constructeur qui ressemblerait à

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
MyClass::MyClass(QWidget * parent):QMainWindow(parent){
    dialogA = new MyDialogA(this);
    connect(dialogA->pushButtonA, &QPusButon::clicked, this, &MyClass::slotActionA);
    dialogB = new MyDialogB(this);
    connect(dialogB->pushButtonB, &QPusButon::clicked, this, &MyClass::slotActionB);
}

et un code pour les autres fonctions (slotActionA, slotActionB et commonPart) qui serait proche de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
void MyClass::slotActionA(){
    /* la partie spécifique à l'action A qui arrive éventuellement avant la partie commune 
    * ... 
    */
    commonPart(); // la partie commune aux deux actions
   /* la partie spécifique à l'action A qui arrive éventuellement après la partie commune
    * ... 
    */
}
void MyClass::slotActionB(){
    /* la partie spécifique à l'action B qui arrive éventuellement avant la partie commune 
    * ... 
    */
    commonPart(); // la partie commune aux deux actions
   /* la partie spécifique à l'action B qui arrive éventuellement après la partie commune
    * ... 
    */
}
void MyClass::commonPart(){
    /* tout ce qui doit être effectué, indépendamment du slot qui sera appelé */
}

Dis toi que, de manière générale, il est absolument nécessaire de respecter ce que l'on appelle le SRP (pour Single Responsability Principle, ou le "principe de la responsabilité unique" en français): chaque classe, chaque fonction, chaque donnée ne doit être utilisée que dans un but bien précis, pour rendre un type de service bien particulier.

Si une fonction, une donnée ou un type de donné se retrouve à avoir plus d'une seule responsabilité, c'est -- très clairement -- que cette fonction, cette donnée ou ce type de donnée se retrouve avec trop de responsabilité .

En voulant rendre un seul slot responsable de la mise en oeuvre de deux actions différentes, tu en viens à vouloir donner... deux responsabilités différentes à ton slot.

En tant que débutant, tu crois sans doute que ce sera une bonne idée de travailler de la sorte, mais je peux t'assurer, en tant que vieux de la vieille que ce serait une très mauvaise idée . Je suis tout à fait disposé, si tu m'en fais la demande à t'expliquer plus clairement les raisons pour lesquelles ce serait une fausse bonne idée ... Pour autant que cela t'intéresse, bien sur

[lkr22]

Merci de ta réponse, j'ai effectué une méthode différente en faisant 2 méthodes sans faire une méthode pour les parties communes comme tu me l'as conseillé, j'essayerai d'améliorer mon code avec ta méthode.

Merci à toi !

[koala01]

Merci de ta réponse, j'ai effectué une méthode différente en faisant 2 méthodes sans faire une méthode pour les parties communes comme tu me l'as conseillé,

Soyons clairs, je ne connais pas ton projet. Je n'ai donc absolument aucun moyen de savoir si c'est nécessaire ou non .

Mais, SI "une certaine partie de la logique" de tes deux slots est identique, tu peux me croire sur parole : tu as très largement intérêt à créer une fonction qui prendra "cette partie" de la logique en charge.

En Xtrem programming il existe même l'interjection DRY (pour Don't Repeat Yourself ou, si tu préfères en français : ne vous répétez pas) pour t'inciter à agir de la sorte.

Car, pour l'instant, tu te trouve avec une application qui doit réagir à l'appui sur deux boutons différents, et pour laquelle tu vas donc créer deux slots différents.

Si "une certaine partie" de la réaction de ces deux slots est identique, tu pourrais te retrouver dans une situation proche de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
/* le premier slot */
void MyClass::slotActionA(){
    // il y a tout une partie qui est spécifique au slot A pour commencer
   /* suivent une diszaine de lignes communes aux slots A et B */
  // il y a toute une partie qui est spécifique au slot A pour terminer
}
void MyClass::slotActionB(){
    // il y a tout une partie qui est spécifique au slot B pour commencer
   /* suivent une diszaine de lignes communes aux slots A et B */
  // il y a toute une partie qui est spécifique au slot B pour terminer
}

Ca semble cool, comme cela, non

Sauf que la pratique est tout autre

D'abord, tu dois te dire qu'il est "de pratique courante" de considérer qu'une fonction qui fait plus de vingt lignes est sans doute une fonction trop grande.

Bien sur, le nombre de vingt lignes est purement arbitraire, mais il se justifie malgré tout par le fait que, si une fonction ne prend effectivement qu'une seule responsabilité, il est **généralement** tout à fait possible de l'exprimer en (beaucoup) moins de vingt lignes.

Par contre, si une partie de la logique nécessite déjà dix lignes pour pouvoir être exprimée et qu'elle s'avère être commune à plusieurs fonctions, cela ne laisse plus que ... 10 lignes pour exprimer les parties spécifiques aux différentes fonctions qui auront besoin de cette "partie commune". Et il n'y a rien à faire : dix lignes, c'est souvent assez limité pour exprimer une logique complexe

Et puis, il y a un autre problème...

A l'heure actuelle, tu as déjà deux slot (le slot A et le slot B) qui vont réagir au clique sur un bouton bien particulier de deux formulaires différents. Je ne dis pas que c'est exactement la situation dans laquelle tu te trouves, mais, pour les besoins de ma cause, on va considérer que ces deux slots doivent -- pour une raison quelconque -- appliquer une partie de logique qui est identique.

Si tu as, déjà aujourd'hui, alors que tu n'es qu'au tout début de ton développement, tu as deux slots dans cette situation, tu peux te dire que dans "quelques mois", tu auras sans doute cinq, dix ou quinze slots qui seront dans cette situation; et cela pour une raison bien simple : les besoins évoluent sans cesse.

Et, du coup, même si on accepte l'idée que "le nombre de vingt lignes maximum par fonction" est d'avantage un conseil qu'autre chose (conseil que l'on va s'empresser de ne pas respecter, sans doute), on va se retrouver avec cinq, dix ou quinze fois avec "une partie" du code de chaque slot qui est... strictement identique pour tous les slots.

Tu serais parfaitement en droit de me demander en quoi cela peut bien me gêner... Car, après tout, c'est vrai tien : où pourrait bien être le problème Et bien, je vais te le dire, moi, où serait le problème: l'homme est faillible par nature, et, si on lui laisse la possibilité de faire une connerie, ce n'est qu'une question de temps pour qu'il la fasse.

Si bien qu'il y a "de fortes chances" pour que les dix lignes qui correspondent à "la partie commune" de la logique de tes différents slots ... contiennent une erreur Et cette erreur sera -- forcément -- recopiée dans ... les dix ou les quinze slots qui ont besoin de la partie commune

"Manque de bol", tu ne dois pas t'attendre à ce que l'utilisateur te dise que le problème survient "dans la partie commune à l'ensemble des slots"... Car lui, il va t'exprimer les choses de son point de vue : j'ai un problème quand je clique sur le bouton machin du formulaire bidule : il se passe ceci (ou cela)".

Et, toi, tu vas donc aller corriger... le slot qui correspond au clique sur le bouton machin du formulaire bidule. Oui, mais, cela signifie que si le problème survient effectivement -- c'est vraiment pas de bol, hein -- dans la partie commune au quinze slots qui existe, tu vas te retrouver avec quatorze autres slots qui posent encore et toujours le même problème

Allez, pensons positif : avec un peu de chance, tu viendras "tout juste" de copier cette partie commune dans le seizième slot, pour pouvoir rajouter une fonctionnalité supplémentaire. Et tu penseras donc **peut-être** à corriger la logique dans ce dernier slot.

Mais il faudra énormément de chance pour que tu te souvienne de plus de deux ou trois slots qui utilisent cette logique commune, ce qui en laissera toujours ... une grosse dizaine de coté

Et, le résultat des courses, c'est que tu vas diffuser la correction dans les "quelques slots" auxquels tu as pensé, mais que, un mois plus tard, tu auras ... un nouveau rapport de bug pour l'un des slots qui n'a pas été corrigés Et tu risques très fort d'avoir, à différents moments, un rapport de bug pour chaque slot utilisant la partie commune de la logique .

Voilà donc un parfait exemple de ce que l'on pourrait appeler du "travail inutile". Car, il faut pas se leurrer : tout le temps que tu va passer à corriger les quinze slots, c'est du temps que tu ne pourras pas passer à développer une fonctionnalité supplémentaire

Ne commet surtout pas l'erreur que "tu es un dieu" et que tu ne fais aucune erreur dans ta programmation! Cela fait plus de quinze ans que je suis dans le développement, et je suis considéré comme un expert du langage et des "bonnes pratiques" par certains. Cela ne m'empêche pourtant pas de faire encore des erreurs dans ma programmation.

J'en ferai sans doute (beaucoup) moins que toi qui débute, mais elles seront sans aucun doute beaucoup plus graves et plus difficiles à repérer et à corriger

Facilites toi donc la vie autant que faire se peut : si tu trouve deux fois le même code (ou du code "sensiblement identique", aux noms de variables près) dans deux slots différents (ou plus), crée toi une fonction qui reprend ce code, et fais y appel depuis "tous les slots qui en ont besoin".

De cette manière, si, pour une raison ou une autre, tu devait corriger le code de cette partie identique, le simple fait de corriger le code de cette "fonction supplémentaire" fera que la correction serait appliquée... partout où elle serait nécessaire, ce qui t'évitera de devoir la corriger encore et encore dans "un autre slot que tu avais oublié".

NOTA: J'ai parlé tout au long de cette intervention de "slots", mais il va sans dire que le principe est valable pour n'importe quelle fonction, vu qu'un slot n'est jamais qu'une fonction qui est appelée automatiquement lorsqu'un signal est émis