Discussion :

[StormimOn]

Bonjour,

Je suis confronté à un petit problème d'architecture. Je dois générer un fichier XML correspond à un protocole, sachant que la version N+1 du protocole englobe forcément la version N de ce dernier.

Pour générer le fichier XML, j'ai pensé à la sérialisation puisque le fichier est relativement simple et s'y prête plutôt bien. Ensuite, comme la version N+1 du protocole englobe la version N, on se dit que l'héritage irait bien avec ce genre de système, en dérivant la classe de la version N du protocole pour y ajouter les nouveautés de la version N+1. Les classes seraient relativement simples car il n'y aurait des des champs / propriétés.



Le problème c'est que suivant la version du protocole utilisée, on va manipuler une classe différente (ProtocolV1 pour la version 1, ProtocolV2 pour la version 2, ...). J'aimerais n'avoir qu'un seul point d'entrée (BaseProtocol) quelle que soit la version du protocole, ce serait plus simple d'utilisation, et là je coince.

C'est un peu comme si j'avais tout dans une seule classe (BaseProtocol), avec des propriétés dont la visibilité (private, protected) serait conditionnée par la version du protocole.

J'ai bien pensé à la possibilité de générer un assembly par le code mais ca ne me plait pas trop et je ne suis même pas sûr que ca réponde à mon problème. Si vous avez des idées, je suis preneur.

[Mose]

Je comprend pas bien le pb...

C'ests normal d'avoir des types différents, étant donné que tes objets vont avoir du contenu et des méthodes différentes.

C'est effectivement utile d'avoir une classe de base BaseProtocole (que j'appelerai plutôt ProtocolBase pour qu'ils soient à côté dans l'intellisense et NDoc)

Mais pourquoi tu devrais avoir tout tout tout dans ProtocoleBase ? Le principe de base en objet c'est d'y mettre exclusivement les méthodes et données qui seront systématiquement présentes dans tous tes protocoles. C'est la base du polymorphisme.

Si tu veux que ton ProtocoleBase contienne les méthodes de la V1 et aussi de la V2, alors ça ne sert plus à rien d'utiliser des types.

[StormimOn]

Je sais bien que c'est normal d'avoir des types différents et je connais le polymorphisme. Je veux bien croire que je ne suis pas un as mais je connais les bases

Le problème, c'est que l'on m'impose de fournir un point d'entrée unique (ProtocolBase donc) et de pouvoir traiter toutes les versions du protocole avec ce point d'entrée.

Ce que je vais faire c'est de déclarer toutes les propriétés d'accès en lecture/écriture comme virtuelles sur ProtocolBase, en leur faisant renvoyer une exception comme quoi la fonctionnalité n'est pas présente. Ensuite, chaque version du protocole redéfinira les propriétés (fonctionnalités) qu'elle est capable de prendre en charge.

[Mose]

Ouais oki, j'avais bien compris, mais c'est pas objet comme conception
C'est de la bidouille.

Qu'on te l'impose, je le déplore, mais ton architecte est un rigolo qui n'a pas compris à quoi servait le typage.

Rassures-le, ce n'est pas le seul charlot sur terre. Même les équipes de MS font des conneries dans ce genre.
Exemple, la classe Array implément IList.
Ca fonctionne, oui, c'est sûr, mais c'est crado, anti-intuitif, et ça oblige à faire des tas de cas particuliers et de try/catch quand tu bosses direct avec les IList.
(Moralité : on bosse jamais avec IList directement, donc l'interface ne sert à rien)

Oui oui, je suis un puriste, mais je conçois des outils qui cherchent à automatiser tout un tas de trucs et ce genre de conneries ça me fait perdre un temps fou.

[StormimOn]

Je sais que cette conception est pas très objet.

D'un autre côté, je peux comprendre que l'on souhaite procéder ainsi. Dans l'image que j'ai posté, j'ai volontairement simplifié ce qu'il y a derrière. Le XML que l'on crée est issu d'un protocole plus compliqué que ca en pratique. En gros, on a 8 catégories avec différentes rubriques par catégories (3 à 5 suivant la catégorie) et de possibles sous-catégories (jusqu'a 5 niveaux).

Pour une version 1 du protocole, ca donne pour certaines catégories une vingtaine de classes qui vont gérer la catégorie en question (sachant qu'il y en a 8). Si on a pas un point d'entrée unique, ce qui n'est pas très objet dans la conception comme tu le dis, ca deviendra vite le bordel pour le développeur qui utilisera les objets métier "protocole".

Si il faut pouvoir gérer 4 ou 5 versions du protocole en même temps, cela fera un nombre de points d'entrée bien trop important et, pour ma part, il ne faut pas que le développeur métier ait à se soucier de tester la version du protocole qu'il utilise pour créer les bons objets. C'est plus simple de lui renvoyer un point d'entrée unique, en fonction d'une version du protocole demandée, sachant que les fonctionnalités non gérées renverront une exception, suivant l'objet métier.

Mais bon, peut être que je fais fausse piste sur la manière de procéder après tout.

[Mose]

Si tu penses que ce sera plus simple pour le développeur, pourquoi pas.

Le risque que je vois dans cette conception, c'est que finalement, tu vas reporter la complexité au niveau de l'utilisation de tes objets, les rendant pas très developper-friendly.
Ex :
* je récupère mon ProtocoleBase
* j'appelle la méthode "FaireTruc" dans un try catch
* Si ça a marché alors ....
* si ça n'a pas marché alors ....

Au final, :
* ça risque de faire plein de code en plus pour tester les fonctionnalités (si elle ne servent qu'à un endroit c pas trop grave, mais sinon...)
* ça diminue les perfs (la gestion d'exception c'est bien plus lent que le renvoi d'un booléen)

Moi ce que je ferais (sans prétention, à ce que j'ai compris de ta problématique), C'est utiliser les interfaces pour faire un modèle objet conceptuel parallèle (Oulala, désolé, j'ai pas trouvé de mot tout fait pour dire ce que je pense).
En gros, tu fait une interface par fonctionnalité.
Comme ça au lieu que tes développeurs ne récupèrent un objet protocole à tout faire, ils récupérent un objet chargé de cette fonctionnalité.
Si la fonctionnalité n'existe pas pour ce protocole, alors elle n'est pas implémentée, c'est tout.

Après, pour simplifier l'utilisation et la récupération de ces interfaces, tu peux faire un point d'entrée unique : une classe avec des méthode statiques pour récupérer les bonnes instances de ces interfaces, ou nulle si cette fonctionnalité n'est pas implémentée.
(Pitain g l'impression de pas être clair là...)

Je peux être plus clair mais alors :
* Comment tes dev récupèrent ton instance de protocole ?
* est ce que, par héritage, tu veux pouvoir bloquer des fonctionnalités dans une classe fille, ou seulement les étendre ?

[kbenka]

J'ai suivi cette passe d'arme avec interet ;-)
Brain n'a pas tord mais je comprend ta problematique!
Pour les cast il a 100% raison, j'ai travaillé sur pas mal de projet!
C'est l'ultime recours vaux mieux passer par une interface c plus propre.
Pour ton probleme de conception, ton role est de fournir une boite noire simple a utiliser.
Il y a aussi une question d'experience!
Nous avons tous cette problematique, faire du code propre, evolutif, facile a maintenir.
On parle beaucoup du developpement ASPECT, qui repousse les limites de l'appoche objet.
A mon avis tes objets devrait avoir un faible couplage entre eux c mieux
Sur codeproject tu as des article de Hamilton à ce sujet.
Try and catch non pas ça !!!!! ;-)

[StormimOn]

Pour ton probleme de conception, ton role est de fournir une boite noire simple a utiliser.

C'est tout à fait ca.

A mon avis tes objets devrait avoir un faible couplage entre eux c mieux. Sur codeproject tu as des article de Hamilton à ce sujet.

Je vais regarder ces articles. J'avais vu, mais pas encore lu, celui sur l'inversion de contrôle (Chris Hamilton), entre couplage fort et faible. Mais même après avoir lu ça, je ne pense pas trouver la solution utilme à ce problème, car au final le problème se situe plus dans le cadre de la définition d'une structure d'accueil pour les données, étant donné que les fonctionnalités seront à un autre niveau.

J'essairai de fournir un diagramme UML plus étoffé, mais avec des noms bidons, pour une meilleure vue d'ensemble peut être, si vous êtes toujours d'accord pour essayer de m'aider