Discussion :

[Nip]

Bonjour à tous,

donc voilà j'ai à nouveau besoin de vos avis d'experts ; je développe une appli en tachant de respecter les bonnes pratiques d'architectures et ainsi faire en sorte que le couplage entre les différentes couches soit le plus faible possible.
Je dispose donc d'interfaces de mes objets métiers et de mes classes; afin de maintenir ce faible couplage j'ai utilisé le design pattern decorateur qui implémente mes interfaces métier correspondantes.
Or là où se pose mon problème c'est que dans le modèle que j'ai développé, j'utilise l'héritage : je me retrouve donc avec une classe mère et 3 classes filles que je dois "cacher" par les décorateurs correspondants. Du coup je ne sais pas comment représenté cette relation au niveau de mes décorateurs sans affecter mon architecture.

Merci d'avance pour les conseils que vous me donnerez.

[oca]

le code par rapport à des interfaces est déjà une très bonne chose,
sinon, bon... comme ca..., j'ai l'impression que
le decorateur n'est pas forcement le design le plus adapté
pour de l'isolation... j'aurai plus vu des Adapter dans ma boule de cristal...
mais sans rien connaitre de ce que tu fais, c'est dur à dire....

A+
Olivier

[Nip]

Merci pour la rapidité de ta réponse oca. Alors effectivement je conçois qu'il est difficile de me donner une réponse plus précise vu le peu d'indications que j'ai fourni. Donc je vais tâcher d'être un peu plus clair.
Première chose ma couche d'accès aux données est générée automatiquement via un outil de mapping O/R; or ces classes générées n'impléméntent aucune interface(interfaces qui sont la garantie du faible couplage entre les couches). J'ai utilisé le pattern decorateur pour chaque classe générée automatiquement. Ce décorateur implémente donc l'interface métier correspondante (Note : je dois conserver ce design pattern et je ne peux pas par conséquent le remplacer par le pattern adapter).
Dans mon diagramme de classe j'ai une classe personne qui est mère de 3 autres classes possédant chacune des attributs spécifiques.
Mon problème se situe en fait au niveau du comportement de mes classes héritées. Je ne sais pas quelle est la meilleure chose à faire afin de conserver toute la transparence entre les couches; en effet les décorateurs implémentent mes interfaces; je ne sais pas comment faire pour les attributs hérités et si je dois passer par l'utilisation d'un autre pattern comme l'Adapter; ou alors si j'indique à mes interfaces l'existence de l'héritage (ce que je pense qui est mal puisque on donne une idée de la conception objet), ou je donne juste le nom des attributs de la classe mère aux classes filles.

Bref je me pose beaucoup de questions sur la "propreté" de l'utilisation de l'héritage dans le cadre du développement d'une application respectant les bonnes pratiques d'architecture (héritage dont je ne vois malheureusement pas comment y échapper dans mon cas) et je ne vous cache pas que tout ceci est un peu confus pour moi.

[oca]

Tout d'abord, je peux jetter ma boule de cristal, car le
pattern adapter n'amène rien ici...

pour ce qui est du decorateur, je n'y avais jamais vraiment réfléchis...

Si je comprends bien, tu as une sorte de value object (vo)
qui correspond aux données d'une/plusieurs table(s), et tu décores ce vo
avec des fonctionalités métiers c'est bien ça ?

Un design plus courant est le suivant :

les vo sont remplis par des dao qui sont utilisés par des services qui
sont eux même accedé par des beans 'écran'

Dans le cas d'un héritage de personne <- personnePhysique par ex,
je ferais hériter mes vo , voir peut-être mes services.
pour moi, l'hértige ne melange pas les couches tant que le
service n'étend pas le vo. par contre, il faut bien que tout cela interagisse
au bout d'un moment... donc le vo est connu de mon service (retourné
par le dao).

qui s'occupe de chargé le vo chez toi ?
1 dao ?

[ego]

Un peu de code permettrait de mieux comprendre vos commentaires qui laissent trop de place à l'interprétation du lecteur.
Par exemple, je ne vois pas pourquoi tu parles du DP Decorator !?

Du code, du code...

Et mieux, un modèle UML !!

[Nip]

En fait pour essayer d'etre assez clair (enfin essayer): je développe une appli selon le modèle 3 tiers (couche de présentation, couche de services et couche d'accès aux données), en ayant la volonté de réduire au maximum le couplage entre chaque couche
Ma couche d'accès aux données est générée automatiquement via un outil de Mapping O/R. J'ai donc des objets métiers qui n'impléméntent aucune interface. Afin de pallier à ce problème j'utilise le DP decorator qui est chargé d'implémenter l'interface métier correspondante. Du coup dès que ma couche de présentation voudra récupérer des objets métier (en passant par la couche de service), c'est une instance de mon décorateur qui sera renvoyée.
Je pense que jusque là tout est clair.
Là où se pose mon problème c'est que dans mon modèle UML, j'utilise l'héritage;

ce qui oblige les interfaces pharmacien médecin et autre à hériter de l'interface personne. En fait d'un point de vue purement code ca ne pose pas de problème, mais je me demande si le fait d'utiliser l'héritage ne rompt pas avec la volonté d'appliquer les bonnes pratiques d'architecture (dans le sens où, par exemple, dès que je vais intervenir sur la classe mère, les classes filles seront modifiées sans même avoir touché à leur code, normal mais bon j'aime pas trop quand même ). Je suis d'accord que sur le projet sur lequel je suis en train de bosser, ça ne pose pas de réel problème de mise en oeuvre mais c'est vrai que dès que le projet prend de l'ampleur et que plusieurs personnes bossent dessus ca pourrait vite devenir problématique.
Enfin bon vous aurez compris que cette question est plus "philosophique" (désolé pour le mot un peu pompeux mais j'en ai pas d'autre) que pratique mais bon j'aimerai avoir votre avis à tous la dessus.

[ego]

Sincèrement, je ne comprend pas ton problème.
Si tu as des classes filles, c'est normal que "leur code" soit "modifié" si tu modifies la classe mère; c'est le principe même de la généralisation/spécialisation.
Ton racourci "mes classes sont persistantes donc je n'ai pas d'interfaces" n'est pas un bon argument. Tu peux toujours définir des interfaces pour tes classes persistantes !!
Quand à ton usage du décorateur, je pense que tu te trompe de design pattern. En l'espèce, il semble plutôt que tu utilises un "Value Object" pour tes objets persistants et que tes objets "services" travaillent avec tes VO.
Tu as reproduit le bon vieux couple "données - traitements" mais c'est tout à fait acceptable, voir même recommandé dans certains cas.

Bref, je ne vois pas de gros problème avec tout ce que tu as fait...

[Nip]

Sincèrement, je ne comprend pas ton problème.
Si tu as des classes filles, c'est normal que "leur code" soit "modifié" si tu modifies la classe mère; c'est le principe même de la généralisation/spécialisation.

ben on est d'accord en fait . C'est juste que je suis tomber sur des articles qui m'ont amené à me poser des questions sur l'utilisation de l'héritage.

Ton racourci "mes classes sont persistantes donc je n'ai pas d'interfaces" n'est pas un bon argument. Tu peux toujours définir des interfaces pour tes classes persistantes !!
Quand à ton usage du décorateur, je pense que tu te trompe de design pattern. En l'espèce, il semble plutôt que tu utilises un "Value Object" pour tes objets persistants et que tes objets "services" travaillent avec tes VO.

Pour l'utilisation du DP décorateur je ne me suis pas bien exprimé : la persistance des objets métier est réalisée par l'outil de mapping O/R. Comme les classes générées n'implémentent pas les interfaces, j'ai utilisé comme adaptateur d'impédence, le décorateur, qui fait le lien entre les interfaces métier et les classes générées.

En tout cas le problème est considéré comme résolu et j'ai énormémént apprécié vos remarques.

Voilà