Discussion :

[Freem]

Bonjour
Je suis en train de refaire un logiciel de dessin vectoriel nommé autorealm. (refaire, car il était utilisable uniquement sous windows, et codé en delphi, que je ne maîtrise absolument pas, ce qui m'empêche de faire une "simple" traduction. De plus, le développement s'est arrêté vers 2006, si je ne me trompe pas.)

Vue le (très gros) nombre de fonctionnalités dudit logiciel, j'ai voulu d'abord me concentrer sur la conception et l'architecture.
Au fil de mes réflexions, je me suis dis qu'il était plus intéressant de le diviser en modules "a peu près indépendants" : moteur de rendu, moteur de plug-in, plug-ins et application.

Je me suis lancé dans le code de mon moteur de plug-ins il y à déjà quelques temps, vu que la conception de ce côté me paraît correcte, et j'ai récemment entamé le moteur de rendu.
Seulement j'ai quelques doutes quant au modèle final, car:
_ certaines choses ont un air de famille dans le moteur de rendu, mais je ne parviens pas à les regrouper. Je me demande si je n'ai pas mal utilisé des design pattern, ou pas utilisé les bons.
_ le couplage entre le moteur de plug-in et l'application mère est très fort
_ le couplage entre le moteur de plug-in et les plug-in est également très fort

Donc, j'aimerai avoir quelques avis extérieurs, sachant que le codage n'en est qu'a ses débuts, et qu'il est donc très simple de modifier ce qui a été fait.

J'ai joint à ce sujet le diagramme des classes actuel.

Je rencontre également un certain nombre de problématiques qui me sont totalement inconnue pour le moteur de plug-in: comment donner accès aux fonctionnalités du moteur de rendu sans augmenter drastiquement le couplage?
Donner un accès aux enfants de Visitor ? Ca aurait le mérite de masquer l'accès aux données...

Une dernière chose, j'ai constaté que les Visitor sont étroitement liés aux Visited (logique). Le souci que ça me pose, c'est que dans les cas ou le visité possède une liste d'enfants, la seule solution que j'aie trouvé est de faire un getter sur cette fameuse liste. Ce qui m'ennuie, car du coup ces listes sont accessibles en lecture/écriture à toutes les classes! C'est exactement comme si je les avait mises en public, ce qui me gêne beaucoup. Dans le cas des héritiers de Visitor, c'est normal et voulu, mais on pourrait du coup appeler le getter de l'extérieur: dans l'application ou dans les plug-ins, ce qui n'est pas voulu et ne devrait pas être utile logiquement.

C'est la première fois que j'utilise une architecture orientée plug-ins, et également la première fois que je travaille autant sur la conception avant d'attaquer le code, et je ne connaît pas suffisamment bien les design patterns... donc je suis en proie à pas mal de doutes (en tout cas, j'ai déjà constaté l'intérêt de la conception et des design patterns, j'ai l'impression d'avoir goûté au fruit défendu, je vais avoir du mal à m'en passer à l'avenir du coup)

[edit]
Et au cas ou, le dépôt du code actuel : https://bitbucket.org/bmorel/autorealm