[C# 2.0] Question d'architecture - code dynamique

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.

http://img177.imageshack.us/img177/5...itrece6.th.png

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.

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.

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 :P

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.

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.

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.

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 ?

J'ai bien pensé aux interfaces. Au final, mes fonctionnalités sont l'accès en lecture, lecture/écriture sur des champs, uniquement des propriétés donc.

Il est vrai que je peux faire une interface par version du protocole, en faisant hériter les interfaces (l'interface de la v2 du protocole hérite de celle de la v1 en ajoutant les nouvelles fonctionnalités propre à la v2) et n'avoir qu'une classe qui implémentera l'interface correspondant à la dernière version du protocole. Ensuite, je renvoie l'interface qui correspond à la version que l'on veut traiter. C'est ce à quoi tu pensais ?

Par contre, cela nécessite que le développeur métier cast ensuite l'interface dans le type réel, car l'idéal c'est de n'avoir qu'une méthode qui renverra l'interface en v1, même si l'interface réelle est en v3 par exemple.

C'est sûr, ca fonctionne et c'est plus "propre" que ce que je cherche à faire, mais ca ne passera pas car pas assez "simple" pour les développeurs métier. Ils doivent tester la version du protocole (l'interface posséderait une méthode qui donnerait la version du protocole sous-jascente à l'objet) et ensuite faire le cast vers l'interface réelle. Vu le nombre d'interfaces que ca va générer, ca risque de ne pas passer (par rapport à un système où on ne verra que les classes racines quelle que soit la version du protocole utilisée) car "on" ne veut pas que le développeur ai à se préoccuper de ce genre de choses :)

Je vais quand même voir s'il y'a moyen de négocier avec "on" :P

Pour revenir sur les exceptions, ce n'est pas un problème. Le protocole est connu du métier, donc des développeurs. Ils savent ce qu'ils peuvent et ne peuvent pas faire, suivant les versions, même si je leur met tout à disposition. Ce que je dois faire c'est quelque chose de "simple" pour centraliser tout çà. Donc les exceptions se produiront sûrement en cours d'intégration, mais en déploiement elles ne doivent plus se produire et un unique try/catch global suffira si un cas a été oublié.

Sinon, pour répondre à tes deux questions.

Citation:

---

Comment tes dev récupèrent ton instance de protocole ?

---

J'aurai une classe racine par "catégorie". Cette classe racine sera récupérée au moyen d'une méthode d'une classe statique à laquelle on indiquera la version du protocole que l'on veut utiliser pour avoir l'objet adapté à cette version. Cette classe racine sera un peu comme le XmlDocument, elle me servira a créer chaque élément de l'arborescence avec la bonne version.

Citation:

---

Est ce que, par héritage, tu veux pouvoir bloquer des fonctionnalités dans une classe fille, ou seulement les étendre ?

---

Ce sera en extension, mais également en blocage le cas échéant. Les versions récentes du protocole englobent les versions plus anciennes, mais certaines fonctionnalités ne seront peut être parfois plus utilisables, néanmoins ont les garde pour assurer la compatibilité ascendante.

Citation:

---

Envoyé par StormimOn

Par contre, cela nécessite que le développeur métier cast ensuite l'interface dans le type réel, car l'idéal c'est de n'avoir qu'une méthode qui renverra l'interface en v1, même si l'interface réelle est en v3 par exemple.

---

Ah non, surtout pas de cast dans ce sens là. C'est mal 8O (à utiliser en dernier recours)
Non non, moi je voyais surtout une conceptualisation des choses : arrêter de s'occuper des protocole (et même de savoir quel protocole on utilise), et n'utiliser que des "objets capables de faire tel fonctionnalité".
Genre tu veux écrire, tu va chopper l'objet qui écrit et si y'en a pas, bah tu peux pas écrire, c tout :) C'est intéressant en terme de code (très peu de code, super lisible), mais avec un existant comme le tient, ça demande trop d'efforts aux devs qui ont déjà leurs petites habitudes.

Mais bon, vu ton contexte, j'ai l'impression que c'est pas ce qu'il faut...
(z'ont l'air chiant tes devs ;))

Plus je me relis et plus je me dis que je m'exprime mal. Mais vu le bazar, et mon état actuel, c'est peut être normal. C'est aussi probablement parce que dès le début j'essaye de trouver une solution "propre" alors que ce n'est pas vraiment possible :aie:

La seule fonctionnalité qui existera vraiment, c'est l'écriture du fichier XML qui correspond au protocole, et la lecture d'un tel fichier pour recréer l'arborescence objet correspondante. Tout le reste (98% du bazar en gros) consiste uniquement en un moyen pour fournir les données au système : des classes avec des propriétés, qui serviront de structure d'accueil des données et les moyens de les traiter. L'idée c'est que les développeurs n'aient pas à manipuler eux même le fichier XML et que ce soit transparent. Si un jour on passe à autre chose que le XML, ca ne changerait rien pour eux. Classique dans le principe quoi.

Je ne pense pas qu'il soit possible de conceptualiser cette partie après tout. On pourrait à la rigueur passer par un système où on aurait une collection de couple champ/valeur. Là ca devient générique, c'est certain. Mais maintenant, entre se dire "putain, c'est quoi le nom du champ déjà ?!" et "c'est facile, avec les propriétés on voit les champs disponibles !", le choix est vite fait en terme de lecture et de compréhension du code lors de l'utilisation (en terme métier).

Ca ne me plait pas totalement, on l'avait compris je crois, mais je dois avouer que je ne trouve rien d'autre.

Il faudrait peut être un exemple, sous forme UML, plus complet, pour avoir un meilleur aperçu de l'ensemble et peut être voir jaillir une lumière de la part d'un forumeur :lol:

En tout cas, merci Mose de me répondre depuis le début ;)

Je t'en pris, c'est un plaisir, j'aime bien me torturer avec les problèmes d'archi :)
En revanche, je reconnais aussi que j'ai du mal à m'exprimer... faudrait pouvoir dessiner des schémas sur ce forum, çà serait vraiment TOP !

Sinon, je pense à un truc : plutôt que de faire du try catch dégueu partout, tu peux associer à chaque fonctionnalité un booléan.

Genre :
* méthode FaireLeCafé()
* propriété FaireLeCaféIsPossible à tester avant utilisation
(et surtout pas IsFaireLeCaféPossible sinon ils ne seront pas à côté l'intellisense)
ou
* propriété MarqueDuCafé
* propriété MarqueDuCaféIsAvailable à tester avant utilisation

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 !!!!! ;-)

Citation:

---

Envoyé par kbenka

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

---

C'est tout à fait ca.

Citation:

---

Envoyé par kbenka

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 :P