J'ai un composant d'un éditeur tiers pour manipuler les données des ses
applicatrifs.
Le problème c'est qu'entre 2 version les objets ne portent pas le même
nom.
Exemple pour accèder aux articles:
en version 1: oArticles
en version 2: oArticle2
en version 3: oArticle3
Je voudrais emcapsuler les objets dans une class ou mon objet serait
monArticle et suivant la version de l'objet utiliser oArticles,
oArticles2 ou oArticles3.
Quelle méthode pourrais-je utiliser sachant que la fonction de
recherche renvoi par exemple un objet de type oArticles, oArticle2 ou
oArticle3.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
thierry.bip
C'est un object com ? pourquoi ne pas utiliser toujours la dernière version ?
"Sylfelin" a écrit dans le message de news:
Bonjour,
J'ai un composant d'un éditeur tiers pour manipuler les données des ses applicatrifs.
Le problème c'est qu'entre 2 version les objets ne portent pas le même nom. Exemple pour accèder aux articles: en version 1: oArticles en version 2: oArticle2 en version 3: oArticle3
Je voudrais emcapsuler les objets dans une class ou mon objet serait monArticle et suivant la version de l'objet utiliser oArticles, oArticles2 ou oArticles3.
Quelle méthode pourrais-je utiliser sachant que la fonction de recherche renvoi par exemple un objet de type oArticles, oArticle2 ou oArticle3.
Merci pour vos pistes et vos idées.
--
-------------------------- Merci Sylfelin
C'est un object com ? pourquoi ne pas utiliser toujours la dernière version
?
"Sylfelin" <sylfelin_EN_TROP_@cegetel.net> a écrit dans le message de
news:mn.121e7d8709702366.60937@cegetel.net...
Bonjour,
J'ai un composant d'un éditeur tiers pour manipuler les données des ses
applicatrifs.
Le problème c'est qu'entre 2 version les objets ne portent pas le même
nom.
Exemple pour accèder aux articles:
en version 1: oArticles
en version 2: oArticle2
en version 3: oArticle3
Je voudrais emcapsuler les objets dans une class ou mon objet serait
monArticle et suivant la version de l'objet utiliser oArticles, oArticles2
ou oArticles3.
Quelle méthode pourrais-je utiliser sachant que la fonction de recherche
renvoi par exemple un objet de type oArticles, oArticle2 ou oArticle3.
C'est un object com ? pourquoi ne pas utiliser toujours la dernière version ?
"Sylfelin" a écrit dans le message de news:
Bonjour,
J'ai un composant d'un éditeur tiers pour manipuler les données des ses applicatrifs.
Le problème c'est qu'entre 2 version les objets ne portent pas le même nom. Exemple pour accèder aux articles: en version 1: oArticles en version 2: oArticle2 en version 3: oArticle3
Je voudrais emcapsuler les objets dans une class ou mon objet serait monArticle et suivant la version de l'objet utiliser oArticles, oArticles2 ou oArticles3.
Quelle méthode pourrais-je utiliser sachant que la fonction de recherche renvoi par exemple un objet de type oArticles, oArticle2 ou oArticle3.
Merci pour vos pistes et vos idées.
--
-------------------------- Merci Sylfelin
Sylfelin
thierry.bip a écrit :
C'est un object com ? pourquoi ne pas utiliser toujours la dernière version ?
C'est ce que je veux faire. Mais l'interface I3 et une recopie de I2 qui est une recopie de I1.
Il n'y a pas d'héritage.
Pour chaque interface, chaque méthode est renommée (ex: pour accéder aux clients dans I1 l'interface c'est IClient, dans I2 c'est IClient2 et dans I3 c'est IClient3).
--
-------------------------- Merci Sylfelin
thierry.bip a écrit :
C'est un object com ? pourquoi ne pas utiliser toujours la dernière version ?
C'est ce que je veux faire. Mais l'interface I3 et une recopie de I2
qui est une recopie de I1.
Il n'y a pas d'héritage.
Pour chaque interface, chaque méthode est renommée (ex: pour accéder
aux clients dans I1 l'interface c'est IClient, dans I2 c'est IClient2
et dans I3 c'est IClient3).
C'est un object com ? pourquoi ne pas utiliser toujours la dernière version ?
C'est ce que je veux faire. Mais l'interface I3 et une recopie de I2 qui est une recopie de I1.
Il n'y a pas d'héritage.
Pour chaque interface, chaque méthode est renommée (ex: pour accéder aux clients dans I1 l'interface c'est IClient, dans I2 c'est IClient2 et dans I3 c'est IClient3).
--
-------------------------- Merci Sylfelin
OD
C'est un cas très classique et parfaitement normalement de l'utilisation des interfaces en général et des interfaces COM en particulier.
La règle : une interface est IMMUABLE. En effet, une application compilée pour utiliser une interface planterait si l'interface, de même nom (signature, guid.. peut importe la façon de l'identifier) changeait au rythme des MAJ. !
La bonne pratique : Une interface ne doit JAMAIS être modifiée. On en créé une NOUVELLE qui recopie les comportements de l'ancienne et qui ajoute les nouveaux comportements.
Maintenant tu comprends mieux ton cas de figure... Ainis, ton soft compilé, s'il supporte la version 1, il ne peut voir que oArticles et ses méthodes. Point barre. L'objet réel qui est en dessous, même s'il contient des choses en plus, même si implémentation a totalement changé dans la version 2 ou 54, pour ton soft ça marche toujours... Grâce à la règle de l'immuabilité des interfaces...
Donc à toi de choisir quel niveau tu supportes...
--
Olivi3r_____
Dot.Blog - C# LINQ VS ... www.e-naxos.com/blog
C'est un cas très classique et parfaitement normalement de
l'utilisation des interfaces en général et des interfaces COM en
particulier.
La règle : une interface est IMMUABLE.
En effet, une application compilée pour utiliser une interface
planterait si l'interface, de même nom (signature, guid.. peut importe
la façon de l'identifier) changeait au rythme des MAJ. !
La bonne pratique : Une interface ne doit JAMAIS être modifiée. On en
créé une NOUVELLE qui recopie les comportements de l'ancienne et qui
ajoute les nouveaux comportements.
Maintenant tu comprends mieux ton cas de figure...
Ainis, ton soft compilé, s'il supporte la version 1, il ne peut voir
que oArticles et ses méthodes. Point barre. L'objet réel qui est en
dessous, même s'il contient des choses en plus, même si implémentation
a totalement changé dans la version 2 ou 54, pour ton soft ça marche
toujours... Grâce à la règle de l'immuabilité des interfaces...
C'est un cas très classique et parfaitement normalement de l'utilisation des interfaces en général et des interfaces COM en particulier.
La règle : une interface est IMMUABLE. En effet, une application compilée pour utiliser une interface planterait si l'interface, de même nom (signature, guid.. peut importe la façon de l'identifier) changeait au rythme des MAJ. !
La bonne pratique : Une interface ne doit JAMAIS être modifiée. On en créé une NOUVELLE qui recopie les comportements de l'ancienne et qui ajoute les nouveaux comportements.
Maintenant tu comprends mieux ton cas de figure... Ainis, ton soft compilé, s'il supporte la version 1, il ne peut voir que oArticles et ses méthodes. Point barre. L'objet réel qui est en dessous, même s'il contient des choses en plus, même si implémentation a totalement changé dans la version 2 ou 54, pour ton soft ça marche toujours... Grâce à la règle de l'immuabilité des interfaces...
