Objets Automation et Interface

Salut tout le monde,

je suis en train de faire des objets automation.

Je désire pouvoir transtyper une Interface en sa CoClasse associée (je ne suis pas sûr qu'on l'appelle la CoClasse en fait), mais il me met ce message d'erreur :

Citation:

---

Types incompatibles : 'TUser' et 'IUser'

---

Les interfaces ne possèdent aucun champs, je les ai donc mis dans la classe associée pour pouvoir travailler avec. Lorsqu'une interface est passée en paramètre, je désire pouvoir la transtyper afin de récupérer les champs et travailler avec.

Voici un bout de code pour que vous voyez ce que j'essaie de faire :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

TUser = class( TAutoObject, IUser ) private FNom : WideString; public function Traiter( aUser : IUser ) : WideString; safecall; function Nom : WideString; end;   implementation   function TUser.Traiter( aUser : IUser ) : WideString; begin Result := TUser( IUser ).Nom; end;

---

Ce n'est pas exactement le nom que je désire récupérer, j'ai fait un exemple plus simple pour que vous comprenniez sans avoir à tout expliquer. La solution dans ce cas étant de définir Nom dans IUser, mais le soucis n'est pas là. Je désire pouvoir transtyper IUser en TUser et il ne veut pas.

Merci pour votre aide.

En fait, pour faire plus simple, j'ai une interface IUser :

Code:

---

1 2 3

IUser = interface( IDispatch ) // ... end;

---

Et un objet qui dérive de cette interface et de TAutoObject :

Code:

---

1 2 3

TUser = class( TAutoObject, IUser ) // ... end;

---

Dans une méthode, j'ai une interface passée en paramètre que je souhaite transtyper en TUser en utilisant as mais il refuse avec message d'erreur à la compilation :

Citation:

---

Types incompatibles : 'TUser' et 'IUser'

---

Si j'essaie de faire un TUser( IUser ).... il remonte n'importe quoi, le transtypage ne se fait pas comme il faut.

Mauvaise nouvelle, je viens de trouver une partie de la réponse ici :
http://www.developpez.net/forums/sho...ce+transtypage
Il faut donc utiliser un pointeur qui renverra vers la CoClasse.

Le soucis est que je fais une bibliothèque de type et si je veux être compatible .NET, je ne peux pas utiliser les pointeurs.

Faut que je trouve une autre solution.

De fait, c'est impossible. Une référence de type interface cache par définition totalement les références à l'objet qui implémente cette interface.

Il est possible de récupérer des références vers les autres interfaces qu'implémente l'objet référencé, mais pas l'objet lui-même.

En effet, si tu es en inter-langages (domaine pour lequel ont été créées les interfaces), tu ne peux pas obtenir une référence valable à un objet.

Je crois vraiment qu'il y a un problème de conception dans ta solution, car ce n'est pas du tout le but des interfaces de permettre d'obtenir une référence à l'objet.

Pour faire une bibliothèque de type, on déclare des interfaces qui serront distribuées et les utilisateurs utiliseront ces interfaces.

Mais il faut aussi créer les classes qui vont implémenter ces interfaces, ces classes ne sont pas visibles pour l'utilisateur final, mais son inclues dans la bibliothèque de type, c'est en quelque sorte l'implémentation des interfaces.

Les interfaces ne possèdent pas de champs, je les inclue dans les classes qui les implémentent.
Dans les méthodes des interfaces, je ne peux pas passer une classe qui l'implémente (elles ne sont pas visibles pour l'utilisateur), je ne passe que des interfaces.
Par contre, dans l'implémentation de la méthode, je souhaite pouvoir récupérer les champs des classes qui implémentent les interfaces passées en paramètre.

Peut-être dois-je trouver une autre solution, à priori, c'était celle qui me parraissaît le plus simple, mais ce n'est pas possible. Dans mon idée, il n'y avait pas de soucis de classes visibles de l'extérieur, il n'y avait que des interfaces.

J'ai vu une solution qui serrait de renvoyer un pointeur sur l'instance mais dans les objets automation, il n'y a pas le type pointeur possible et ce n'est pas compatible avec .NET.

Je vais essayer de faire un exemple plus parlant parce que je pense ne pas avoir bien expliqué mon cas, et si je ne m'y prends pas comme il faut, comment pourrais-je m'y prendre autrement ?

Dans le fichier TLB, voici la définition de l'Interface (ce n'est qu'un exemple) :

Code:

---

1 2 3 4 5 6

IUser = interface(IDispatch) ['{5C266B02-7627-44C0-9388-7007081CF523}'] function Get_Nom: WideString; safecall; procedure Add( const aUser : IUser ); safecall; property Nom: WideString read Get_Nom; end;

---

Et la classe générée qui implémente les méthodes de IUser :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

TUser = class( TAutoObject, IUser ) private FNom : string; FMyUser : TMyUser; // objet dérivant de TComponent, utilisé dans l'application   protected function Get_Nom: WideString; safecall; procedure Add( const aUser : IUser ); safecall;   public property MyUser : TMyUser read FMyUser write FMyUser; end;   implementation   function TMyUser.Get_Nom: WideString; begin Result := FMyUser.Nom; end;   procedure Add( const aUser : IUser ); begin FMyUser.Add( ( aUser as TUser ).MyUser ); // <- Ici le FMyUser prend un TMyUser en paramètre, je ne sais pas comment arriver à le récupérer depuis l'interface end;

---

Dans le TLB, il n'y a bien que des interfaces et des types acceptés pour assurer la compatibilité avec les autres langages.

L'architecture que j'ai choisi n'est pas la bonne ? Je pensais que coller les objets automation aux objets de l'application était une bonne idée.

Pourquoi ne fais-tu pas

Code:

---

FMyUser.Add(AUser.MyUser);

---

?

Je ne peux pas parce que MyUser est un objet interne, non visible depuis les interfaces, il est déclaré dans la classe qui implémente et en paramètre je n'ai pas cette classe qui implémente mais l'interface.

C'est bien ce que je disais... Il y a erreur de conception :roll:

Ce que tu peux faire, c'est déclarer une seconde interface IWithMyUser qui ne définit que deux méthodes :

Code:

---

1 2 3 4 5 6 7

IWithMyUser = interface ['{GUID}'] function GetMyUser : TMyUser; procedure SetMyUser(New : TMyUser);   property MyUser read GetMyUser write SetMyUser; end;

---

Ensuite, lorsque tu possèdes une référence à IUser, tu peux tenter de la déréférencer en IWithMyUser. Je dis tenter parce qu'imagine qu'une autre classe implémente ton interface IUser, mais pas IWithMyUser...
(au passage, le const était totalement inutile ;))

Code:

---

1 2 3 4 5 6 7 8 9

procedure TUser.Add(aUser : IUser); begin try FMyUser.Add((aUser as IWithMyUser).MyUser); except on Error : EIntfCastError do // ici il te faut gérer le cas où aUser n'implémente pas IWithMyUser end; end;

---

Ca, c'est un modèle de programmation le plus propre possible pour ta conception de base.

Maintenant, je continue d'affirmer que ce c'est pas top top non plus, car tu supposes que seules tes classes à toi implémente IUser, comme tu le veux, c'est-à-dire avec également une implémentation de IWithMyUser.
Si tu as l'occasion de revoir ta conception, je crois que ce ne serait pas une mauvaise idée :)

J'essaierai ta méthode, tu dis que ma conception est à revoir est qu'elle n'est pas top top, mais je ne vois absolument pas du tout comment le concevoir autrement, c'est là le soucis, j'avais vraiment l'impression que la conception que j'avais faite était la seule bonne conception possible et je me rends compte (parce qu'on ne peut pas transtyper une interface) qu'elle n'est pas bonne, mais je ne vois aucune autre conception possible.

Je suis désolé de revenir encore une fois sur le problème, je suis en train d'essayer de le mettre en place.

Le problème avec ton code est qu'il faudrait que TUser implémente l'interface IWithMyUser, hors en codant ma bibliothèque de type, la déclaration de TUser est automatiquement générée par Delphi et TUser est déclaré comme implémentant IUser et non pas IWhithMyUser.

Je ne vois pas comment faire. :?

En faisant plusieurs tests, je pense avoir trouvé la solution.

Il faut créer IWithMyUser comme interface dérivant de IUser.
Déclarer TUser comme implémentant les 2 interfaces, IUser et IWithMyUser.
Déclarer la méthode de récupération de l'objet TMyUser dans IWithMyUser.

Puis transtyper IUser en IWithMyUser, mais pas avec as le compilateur le refuse, mais en IWithMyUser( IUser ).GetMyUser.

Et ça paraît fonctionner. La solution arrive enfin ! Ouf.

Merci pour ton aide Sjrd.

Citation:

---

Envoyé par WebPac

Déclarer TUser comme implémentant les 2 interfaces, IUser et IWithMyUser.

---

Juste une petite remarque : si IWithMyUser hérite de IUser, il te suffit de déclarer TUser comme implémentant IWithMyUser ;)

Citation:

---

Envoyé par WebPac

Merci pour ton aide Sjrd.

---

De rien ;)

Je vais essayer, en fait, quand j'ai trouvé une solution qui marchait, je n'ai pas voulu insister dessus. Et comme normalement le Concepteur de bibliothèque de type crée lui-même TUser dérivant de IUser, je n'osais le retirer.

C'est quand même bête de devoir déclarer une interface intermédiaire qui ne sert qu'à récupérer une méthode qui n'est pas déclarer dans l'interface de base juste parce qu'on ne peut pas faire de transtypage d'une interface en objet mais juste un transtypage d'interface en interface.

Citation:

---

Envoyé par WebPac

C'est quand même bête de devoir déclarer une interface intermédiaire qui ne sert qu'à récupérer une méthode qui n'est pas déclarer dans l'interface de base juste parce qu'on ne peut pas faire de transtypage d'une interface en objet mais juste un transtypage d'interface en interface.

---

C'est quand même bête de faire fonctionner des interfaces en voulant utiliser les objets qui sont cachés derrières :mouarf: :aie:
Je te l'ai dit : les interfaces ne sont pas faites pour ça, et ce que tu cherches à faire est contre-nature. Il n'est donc pas étonnant que tu doives mettre en oeuvre des acrobaties peu jolies ;)

Citation:

---

Envoyé par sjrd

C'est quand même bête de faire fonctionner des interfaces en voulant utiliser les objets qui sont cachés derrières :mouarf: :aie:
Je te l'ai dit : les interfaces ne sont pas faites pour ça, et ce que tu cherches à faire est contre-nature. Il n'est donc pas étonnant que tu doives mettre en oeuvre des acrobaties peu jolies ;)

---

Je ne comprends toujours pas ce que tu veux dire. Je suis scrupuleusement le tutoriel qui explique comment créer une bibliothèque de type.
Et il faut bien créer des objets qui posséderont l'implémentation du code des interfaces afin que la bibliothèque puisse "fonctionner", sinon ce serrait comme distribuer une simple dll avec des déclarations de fonctions sans code qui exécute derrière, ça ne servirait à rien.

Mon but étant de distribuer une bibliothèque de type complète qui fonctionne sans que les utilisateurs n'aient besoin de recoder aucune fonction définie dans la bibliothèque.

Bien sûr, cela va de soit. Mais il faut bien comprendre que les interfaces sont cross-langages, voire même cross-platforms (je pense). Alors que les objets et les classes, eux, sont intimement liés au langage dont ils sont issus. Et même au compilateur dont ils sont issus.

Une classe compilée avec Turbo Pascal 7.0 n'a pas la même représentation interne que la même classe compilée avec Delphi 2006 ;)

C'est une notion primordiale que celle qui dit qu'on peut aller du plus spécifique au plus général, mais le retour est impossible.

Une interface a une forme universelle qui doit pouvoir être utilisée par n'importe quel autre module codé en n'importe quel langage, avec n'importe quel compilateur.

Si tu pouvais transtyper une interface en classe, tu essaierais d'obtenir quelque chose de spécifique à Delphi à partir de quelque chose qui est par nature général et universel.

Tu vois où ça coince ?

Et je ne parle même pas du comptage de références opéré par les interfaces alors que les classes ne le font pas ;)

Ce n'est pas une limitation ni un "bug" de la notion d'interface : c'est son essence même.

Je comprends le passage sur l'universalité des interfaces et le fait que ce n'est pas le cas des classes. Pourtant, on peut très bien voir une interface comme une simple classe abstraite pure avec toutes ses méthodes virtual abstract.

Le fait est que la bibliothèque ne publie que des interfaces et des types reconnus par tous les langages (donc je ne peux pas utiliser de string, de boolean, de currency...) et les CoClasse qui permettent de créer les objets associés aux interfaces.
Je sais que ça marche ainsi car je le teste avec Visual Studio 2005 en C# et ça marche.

Je transtype sans craindre qu'un utilisateur ne choisisse un autre objet pour implémenter l'interface car il n'en existe pas d'autres, il n'y a pas de raison qu'ils en créent sinon ils peuvent se passer de ma bibliothèque et de plus toutes les variables sont créées par ma bibliothèque et retournées comme si c'était des interfaces mais créées à partir de mes objets.

Citation:

---

Envoyé par sjrd

Si tu pouvais transtyper une interface en classe, tu essaierais d'obtenir quelque chose de spécifique à Delphi à partir de quelque chose qui est par nature général et universel.

---

Surtout qu'une interface n'est pas une classe. Je suis d'avis de Sébastien, tu es en train de torturer une interface pour lui faire avouer qu'elle est qq part une classe, c'est une antinomie.
Que tu atteignes, avec ton pb, les limites du langage Delphi c'est une chose, c'en est une autre de détourner l'usage du concept d'interface qui a, entre autre, été conçu pour limiter le couplage entre classes.
Avec une interface on manipule plus un concept qu'une instance de classe.

Voir aussi ce code de hack,rechercher le terme GetImplementingObject dans cette page.
Ce code confirme, à mon avis,les propos de Sébastien concernant la spécificité, dans ton cas, du code résolvant ce problème.
Et ce n'est pas parce que c'est possible qu'il faut l'utiliser ;)

Les interfaces permettent de travailler en gardant une abstraction sur l'implémentation, mais de toute façon, une interface en elle même ne sert à rien s'il n'y a pas de classe qui les implémente.
On ne peut pas instancier une interface, il faut obligatoirement instancier une classe qui implémente l'interface.

C'est moi qui suis responsable de gérer le code issu des interfaces, ce n'est pas aux utilisateurs qui utiliseront les interfaces sans savoir le code caché derrière.

J'ai déjà fait un certain nombre d'objets métiers qui tournent déjà dans plusieurs applications, ce ne sont pas des objets automation. Les applications ne sont pas non plus des serveurs automation.

Je désire pouvoir distribuer une bibliothèque de type associée à ces applications qui permettrait de travailler avec ces objets métiers, quelque soit le langage.
Je crée donc autant d'objet automation qu'il n'y a d'objet métier, qui leur "colle à la peau", chaque méthode et propriété des objets automations appelleront des méthodes et propriétés des objets métiers.

Seules les interfaces sont publiées et les objets métiers restent internes dans la bibliothèque.

Je pense que les gens qui font des bibliothèques de type travaillent autrement, ils créent directement les interfaces, puis les objets associés et ce sont ceux ci qui auront tout le code métier mais je ne peux pas tout reprendre à 0 et je dois réutiliser ce qui existe et fonctionne. Je ne vois pas d'autre architecture possible pour ma bibliothèque.