Discussion :

[Katian]

Bonjour !

pour simplifier l'appel de plusieurs fonctions qui nécessite le passage en paramètres de plusieurs "services"

Code :

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

void fonction_n(Service1& srv1, Service2& srv2, Service3& srv3 ...etc)

est-ce une bonne pratique d'utiliser le concept de "context" ?

Code :

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

1
2
3
4
5
6
7
8
9
 
struct Context
{
Service1 srv1;
Service2 srv2;
Service3 srv3;
}
 
void fonction_n(Context& context)

ou est-ce à proscrire absolument ?

[Bktero]

Quelle bonne raison vois-tu à le faire ? Quelle mauvaise raison vois-tu à le faire ? Voilà les 2 questions que tu devrais te poser. Tu listes les pour et les contre de ta solution, et comme ça tu peux prendre une décision

[Pyramidev]

Bonjour,

De mon point de vue, c'est une bonne idée, à condition que les fonctions qui prennent en paramètre un Context utilisent bien à la fois Service1, Service2 et Service3 et pas seulement deux parmi les trois. La structure Context permet alors d'écrire un code moins lourd.

Attention, si beaucoup de fonctions ont besoin de ce paramètre de type Context, alors c'est peut-être un signe que le code n'est pas assez découplé (à voir au cas par cas). Mais, de toute façon, ce ne sera pas pire qu'avec des triplets de paramètres Service1& srv1, Service2& srv2 et Service3& srv3.

Au fait, dans ton programme, à quoi correspondent ces classes Service1, Service2 et Service3 ?

[Katian]

Au fait, dans ton programme, à quoi correspondent ces classes Service1, Service2 et Service3 ?

merci à vous !

ces 'services' sont des modules de différents domaines au sein de mon application, rendu graphique, accès fichiers, pool d'objets etc... le but de ce 'context' est d’être passé en argument du design pattern command

en gros résumé :

Code :

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

1
2
3
4
void command::exec(Context& context)
{
...
}

[Bousk]

Si c'est pour le passer de partout, autant mettre des accesseurs globaux directement.

[koala01]

Salut,

merci à vous !

ces 'services' sont des modules de différents domaines au sein de mon application, rendu graphique, accès fichiers, pool d'objets etc... le but de ce 'context' est d’être passé en argument du design pattern command

en gros résumé :

Code :

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

1
2
3
4
void command::exec(Context& context)
{
...
}

De manière générale, il est toujours bon de regrouper les données "qui vont bien ensemble", ne serait ce que pour pouvoir fournir des services qui pourront s'assurer que les invariants soient respectés.

Sauf que, dans le cas présent, je soupçonnes très largement que toute ta conception devrait sans doute être à revoir, car tu te retrouve à mélanger -- l'un dans l'autre -- des informations qui n'ont aucune raison d'être mélangées :

Le rendu graphique fait, en effet -- très clairement -- partie de la vue (le V de MVC), alors que les accès aux fichiers font partie du controller (le C de MVC) et que les pools d'objets font partie du modèle (le M de MVC), des données "business".

Il n'y a donc -- a priori -- aucune raison de commencer à mélanger ces trois éléments dans une fonction, car

• soit, ta fonction s'occupe du rendu graphique, et elle s'en fout pas mal d'afficher un rocher, un oiseau ou un ennemi, ni même de savoir la manière dont les données ont été sauvegardées
• soit ta fonction s'occupe de manipuler un fichier, et elle n'a aucun besoin de s'occuper de l'affichage
• soit ta fonction s'occupe de gérer les données métier et elle se fout pas mal de savoir comment ces données seront sauvegardées et / ou affichées.

Après, il est clair qu'il faut bel et bien, à un moment ou à un autre, en arriver à faire communiquer la vue avec le controller et le controller avec les données métier. Mais, a priori, "tout ce que tu dois faire", c'est t'assurer d'envoyer des messages d'un endroit à l'autre en sachant que, avec un peu de (mal)chance, le message émis sera récupéré par "quelque chose" ... ou non

[r0d]

C'est une question intéressante.
L'utilisation d'un contexte que l'on fait passer en paramètre des fonctions tout au long de la hiérarchie d'appel peut résulter d'une mauvaise compréhension du "static is evil". Si on s'interdit le fait d'avoir des singletons statiques, alors le "context dispatch" est un solution évidente.
Mais s'il comporte beaucoup d'avantage, il cache également quelques pièges dus au fait qu'il complexifie l'état du logiciel.

Déjà, premier écueil à éviter: il faut absolument que le contexte soit passé aux fonctions qui l'utilisent par référence constante. Sinon ça lui ôte tout intérêt.
Ensuite, ça pose tout un tas de problèmes en terme de QA/QC, notamment ça peut rendre très complexe l'implémentation de tests unitaires. Ce problème peut être contourné par l'utilisation de frameworks qui émulent le contexte, mais c'est une solution lourde et complexe qui n'a de sens que sur de très gros projets.

Après, d'un point de vue de l'architecture du logiciel, il faut comprendre ce que l'on fait quand on fait ça: on rend nos objets dépendants du framework. Ce n'est pas toujours ce que l'on veut faire, par exemple lorsqu'on fait du MEF (c'est le premier exemple qui me vient mais il y en a d'autres).

Comme toujours, en général la bonne réponse se trouve au milieu : identifier ce dont les classes vont avoir besoin, décider si ça nécessite une notion de contexte (qu'en général on ne nommera pas "contexte" dans notre code, mais quelque chose de plus représentatif et explicite), et si oui, y mettre uniquement ce dont on a besoin.

Quant au problème de rassembler plusieurs objets dans une structure pour le passer en paramètre de fonction, ça peut aider s'il y a beaucoup de paramètres, mais c'est généralement inutile, et ça fait perdre quelques précieux cycles (si la fonction est appelée 50 fois par frame, ça peut être décisif).