Discussion :

[Emmanuel Deloget]

En étudiant sur Visual ton code, j'ai cru observer un problème. Ton monde connais les salles mais les salles ne connais pas ton monde. ça devrais être l'inverse ou les deux.

Ah non Je m'inscrit en méchant designer qui contre ce que tu dis !

Puisque le monde a l'obligation de connaitre les salles (parce que les salles sont dans le monde; le monde a besoin d'une liste de salles, sans quoi personne ne sait ou sont les salles), cela veut dire que les salles ont l'interdiction de connaître le monde. Dans le cas contraire, on a une référence circulaire, ce qui

1) introduit un couplage fort là ou il n'y en a pas besoin
2) viole certains des principes de conception orientée objet (longue discussion à prévoir sur ce point, donc je ne vais pas entrer dans les détails maintenant).

[Astraya]

C'est nouveau l'évaluation de reinterpret_cast au runtime

Étant donné que à la compilation il ferme les yeux sur le cast, les problèmes ne seront visible que à l'exécution. Ne l'utilisant jamais, je ne sais pas si il prend du temps à l'éxecution mais ce qui est sur c'est que aucune validation du compilateur ne sera faite sur ce cast. C'est à ça que je pense que je dis au "Runtime".

introduit un couplage fort là ou il n'y en a pas besoin

Oui je suis d'accord, dans le code que j'ai donné, il n'y a pas de couplage fort. Juste le contenu connais le conteneur et pas l'inverse (j'ai un raisonnement à l'inverse de l'habitude il est vrai ). Dans ta solution que je trouve aussi meilleur tu donnes des informations mais pas la classe. C'est une manière un peu caché de masqué le couplage, mais il y en a un en réalité sous une autre forme plus perverse. Je donne la classe, tu donnes les informations de la classe.

[koala01]

2) viole certains des principes de conception orientée objet (longue discussion à prévoir sur ce point, donc je ne vais pas entrer dans les détails maintenant).

N'hésite cependant pas, si tu en as le temps/ l'envie / le courage

Nous scinderons la discussion en cas de besoin

[Emmanuel Deloget]

Oui je suis d'accord, dans le code que j'ai donné, il n'y a pas de couplage fort. Juste le contenu connais le conteneur et pas l'inverse (j'ai un raisonnement à l'inverse de l'habitude il est vrai ). Dans ta solution que je trouve aussi meilleur tu donnes des informations mais pas la classe. C'est une manière un peu caché de masqué le couplage, mais il y en a un en réalité sous une autre forme plus perverse. Je donne la classe, tu donnes les informations de la classe.

Je vais même aller plus loin que toi : c'est un couplage aussi. Mais de là à dire qu'il est plus pervers, il y a un pas que je ne sauterais pas


(edit: entre le post de mon message et l'edit, un autre post a été rajouté. Donc je déplace l'édit dans un nouveau post, histoire que tout ça soit plus clair)

[Astraya]

Maintenant on est d'accord pour dire que si on a un schéma comme présenté ici :

A <|-- B ( B hérite de A )
C <|-- D ( D hérite de C )

Si on veux faire communiquer B et D directement sans passé par leur abstraction A et C. Nous n'avons pas le choix de créer un couplage entre les deux. A moins que l'un d'entre vous aurais une solution à apporter pour l'éviter en essayant de conservé un maximum le schéma initiale. La je sèche

[Emmanuel Deloget]

N'hésite cependant pas, si tu en as le temps/ l'envie / le courage

Nous scinderons la discussion en cas de besoin

Temps et courage me manquent aujourd'hui. On verra peut-être demain, mais je doute d'y arriver.

Pour information, j'ai déjà traité courtement d'un type de dépendance circulaire dans cet article, et j'ai aussi un peu bafouiller dessus dans cet autre article, que je me permet de citer, avec l'accord de l'auteur (il a été très sympa avec moi) :

Qu'est-ce qu'une dépendance circulaire ?

Bien évidemment, je pose la question alors que je sais que vous connaissez la réponse. Une dépendance circulaire existe à partir du moment ou une classe A dépends d'elle même de manière indirecte, par opposition à une dépendance directe qui (en termes de design) n'est pas dommageable. Cela signifie que A dépends d'une classe B qui elle même dépends de A.

La conséquence logique est que A et B sont fortement couplées. Ce couplage a un impact non désirable sur à la fois le code et l'architecture.

• Sur l'architecture, ce fort couplage implique que A et B sont nécessairement utilisées ensemble ; ni l'une ni l'autre n'est réutilisable sans l'autre. Si A dépends aussi de plusieurs classes A1, ..., An, alors l'utilisation de B dans un projet nécessite la connaissance de A, A1, ..., An - ce qui n'a pas vraiment de sens. L'architecture est fortement complexifiée du fait même de ce couplage fort.
• Sur le code, une modification dans l'un des deux classes a de grandes chances d'impliquer une modification dans l'autre classe - de manière plus formelle, A est une responsabilité de B qui est une responsabilité de A. En vertu du principe de responsabilité unique, cela signifie que ni A ni B ne peuvent avoir d'autre responsabilité ; conceptuellement, on voit bien qu'il y a un problème, parce que ça voudrait dire que ni A ni B ne font quoi que ce soit.

Certaines personnes semblent penser que dès lors que deux classes présentent une forte cohésion (c'est à dire qu'elles traitent de sujets très similaires et qu'il y a de fortes chances qu'elles soient utilisées dans le même cadre applicatif) alors le fait qu'elles soient en plus fortement couplées n'a pas véritablement d'incidence sur la qualité du design ou sur le code. Ce n'est pas vrai, pour une simple et bonne raison : tôt ou tard, un couplage fort entraine l'utilisation dans un module de dépendances qui n'ont pas de lien de cohésion avec les autres parties du module. La cohésion globale est donc réduite d'autant. A terme, plus le couplage est fort, plus la cohésion du module sera faible. Seul un couplage faible permet de s'assurer d'une forte cohésion entre les différentes classes d'un module.

[koala01]

Maintenant on est d'accord pour dire que si on a un schéma comme présenté ici :

A <|-- B ( B hérite de A )
C <|-- D ( D hérite de C )

Si on veux faire communiquer B et D directement sans passé par leur abstraction A et C. Nous n'avons pas le choix de créer un couplage entre les deux. A moins que l'un d'entre vous aurais une solution à apporter pour l'éviter en essayant de conservé un maximum le schéma initiale. La je sèche

On peut rajouter une classe (voire, une hiérarchie)

Code :

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

1
2
3
4
5
6
7
8
9
A <|-- B
   ^
   | transmet les ordres à 
   |  |<|-- F   ? (F éventuel hérite de E)
   E--|<|- -G  ? (G éventuel hérite de E)
   ^  |<|-- H  ? (H éventuel hérite de E)
   | ordone à 
   |
C <|-- D

où E est un médiateur connaissant l'ensemble des objet dérivés de A

[Emmanuel Deloget]

Maintenant on est d'accord pour dire que si on a un schéma comme présenté ici :

A <|-- B ( B hérite de A )
C <|-- D ( D hérite de C )

Si on veux faire communiquer B et D directement sans passé par leur abstraction A et C. Nous n'avons pas le choix de créer un couplage entre les deux. A moins que l'un d'entre vous aurais une solution à apporter pour l'éviter en essayant de conservé un maximum le schéma initiale. La je sèche

Tout ceci est exact - tu dois coupler B et D. Cependant, lorsque conceptuellement tu as

Code :

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

1
2
3
4
5
 
A <|-- B
*
|
C <|-- D

(A possède des instances de C; pas de losange, désolé)

Alors tu complète avec

Code :

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

1
2
3
4
5
 
A <|-- B
*      *
|      |
C <|-- D

Edit: dans le cas de l'OP, Monde connait Zone, et il n'est pas abhérant que MondeDonjon connaisse ZoneDonjon.

[Astraya]

Très bien très bien.
Mais peut-on voir en soit une faiblesse dans le design si l'on ce retrouve avec ton dernier schéma?

Code :

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

1
2
3
4
5
 
A <|-- B
*      *
|      |
C <|-- D

J'aurais tendance à dire en voyant ça que le code deviendra vite problématique en complexité dans un projet de taille imposante comme un jeu, et qu'il faudrait imaginer une autre solution utilisant la composition plutôt que l'héritage.

[Emmanuel Deloget]

Très bien très bien.
Mais peut-on voir en soit une faiblesse dans le design si l'on ce retrouve avec ton dernier schéma?

Code :

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

1
2
3
4
5
 
A <|-- B
*      *
|      |
C <|-- D

J'aurais tendance à dire en voyant ça que le code deviendra vite problématique en complexité dans un projet de taille imposante comme un jeu, et qu'il faudrait imaginer une autre solution utilisant la composition plutôt que l'héritage.

Ce pattern dont je ne retrouve plus le nom se trouve partout. B spécialise A, donc il est logique que D spécialise C. Dans un jeu ou il y a 36 types de mondes possibles et 400 types de salle possible, le design sur tu proposes nécessite de mettre les caractéristiques utiles à chaque salle dans la classe mère Monde - qui se transforme donc en God Class avec une cohésion très faible - de manière à ce que les 400 classes de salles puisse obtenir les informations qu'elles souhaitent. Dans mon cas, les interfaces des classes la classe mère monde dépends uniquement des fonctionnalités qu'on souhaite y implémenter (getZone, ...). Chaque type de monde est responsable pour initialiser correctement les salles qu'il contient. Et vogue la galère.

Je suis prêt à parier que cette approche est plus maintenable que celle que tu propose

[Astraya]

Je suis prêt à parier que cette approche est plus maintenable que celle que tu propose

Sans aucun doute . Je préfère souvent privilégier la composition à l'héritage et ce ramené à un système de composant. Un TypeDeMonde est composé d'une parti commune (Monde) et d'un parti personnel (ZoneDonjon). Je me rapproche toujours un maximum du principe des Game Object Component. C'est peut-être un défaut, ce n'est pas facile à faire adopter à tout le monde mais c'est bien pratique. Il y a d'ailleurs des présentations à certain GDC la dessus, certains aime d'autre moins.
Les anciens ont leurs petites habitudes bien ancrées je dirais

Edit: Je viens rajouter quelques liens sur des PDF du GDC 2009 et 2010. L'un sur une architecture dynamique de composant pour des hautes performances. Et l'autre mettant face à face la programmation orientée objet classique contre la programmation orientée composant.