Discussion :

[zax-tfh]

Bonjour à tous,

On est en train de se casser la tete avec deux collègues pour mettre en place un truc sympa et pratique sur l'appli que nous développons mais on bloque sur quelque chose.

Imaginons un projet "Library"
Il contient une interface qui sera donc mon contrat exposé au reste du monde.
Il contient également un objet implémentant cette interfaces. Par contre, cet objet n'est pas exposé au reste du monde.
Il contient enfin une classe exposant une fonction qui permet de retourner un objet typé IQuelquechose (donc mon interface). Le return renvoie une instance de ma classe mais le type du retour de fonction est bien mon interface.

Maintenant, je suis dans un projet Lambda qui référence ce projet Library.
Dans ce projet lambda, je créé une classe model qui implémente l'interface.
Je fais appel à la fonction de la classe me retournant mon IQuelquechose et j'essaye d'assigner ce résultat dans une variable typé mon model (qui implémente IQuelquechose) mais cela ne fonctionne pas.

Auriez vous une idée qui permettrai de caster, de convertir le résultat de ma fonction qui est un IQuelquechose (mais qui est encapsulé dans ma classe de mon projet Library) vers mon type model qui implémente lui aussi mon interface ?

On retourne le problème dans tous les sens et cette problématique est vraiment importante pour nous.

[Invité]

Auriez vous une idée qui permettrai de caster, de convertir le résultat de ma fonction qui est un IQuelquechose (mais qui est encapsulé dans ma classe de mon projet Library) vers mon type model qui implémente lui aussi mon interface ?

Ce n'est pas possible.

Si A et B sont des classes implémentant un interface I et que que A et B n'ont aucuns liens de parenté (je veux dire A dérive de B ou inversement) alors il est impossible à partir de B d'avoir un objet A même si les deux classes se trouvent dans la même librairie (donc out le fait qu'elles ne partagent pas la même librairie ou que l'une des classes n'est pas visible du monde extérieur).

La seule solution est de passer par un convertisseur (une classe intermédiaire permettant à partir d'une instance de A créer une instance de B et inversement) ce qui n'est pas du tout propre et oblige à ce que toutes les classes soient visibles par toutes les librairies si elles ne sont pas dans une seule et unique librairie

[zax-tfh]

C'est bien ce que je pensais, merci.
Après je peux peut etre voir pour me faire un petit convertisseur qui, par reflection, va récupérer chaque property de mon interface et pour chacune d'entre elle transferer la valeur de A vers B. C'est pas ultra sex non plus mais ça a le mérite d'etre automatique et niveau perfs, s'il y a maxi 30 property c'est le bout du monde... donc le probleme ne se posera pas. Qu'en penses tu ?

[Invité]

C'est aussi une solution et elle t'évite grâce à la réflexion d'exposer la classe A (confère mon précédent post). Sinon je suis fan d'aucune de ces deux solutions

[Pol63]

si tu as une interface ca devrait te suffire, si tu veux faire une 2ème classe qui implémente ton interface il faudrait nous donner la raison

après si tu veux que ton factory (c'est comme ca qu'on appelle un truc qui retourne une nouvelle instance) retourne une instance de ta 2ème classe plutot que la classe qui est dans la dll c'est possible aussi, même sans référence, il faut faire un mécanisme de "registration de classe"

[zax-tfh]

En fait, le but de la manoeuvre serait de mettre à disposition une brique logique avec ses factory et ses interfaces.
A charge aux appelant de créer leurs propres classes implémentant ces interfaces.

Quel est le but de cette manoeuvre ?

Dans une équipe de devs, on est amenés, entre "secteurs logiciels" (donc entre différents produits), à faire appel à des briques logicielles communes. Néanmoins, l'utilisation directe de classes qui seraient exposées par la brique commune pose problème selon les frameworks employés.
En effet, dans le cas d'un site ASP MVC, on va avoir besoin de dataannotations pour valider les données par exemple.
Dans le cas de Silverlight, on va devoir ajouter la notion de PropertyChanged dans le setter de la property. D'où la nécessité de faire créer leurs propres classes à ceux qui utilisent cette brique logicielle.

Donc une brique hermetique avec juste des interfaces et des factory
Un ou plusieurs "appelants" qui vont créer leurs propres classes implémentant les interfaces et les décorant ensuite avec des mécanismes propres au framework utilisé (j'espere que mon explication est assez claire )

[Skalp]

Il me semble qu'il y a là un problème de conception.

Lorsque l'on manipule des interfaces, c'est qu'on ne veut pas dépendre d'une implémentation en particulier. Pourtant, c'est le cas de la fonction qui retourne une "instance de type IQuelqueChose"

Pourquoi l'objet implémentant l'interface dans le projet Library n'est pas visible de l'extérieur ?

A mon avis :
- C'est dans le projet Lambda que devrait se trouver la fonction qui retourne "instance de type IQuelqueChose" mais en utilisant l'implémentation de IQuelqueChose qui se trouve dans le projet Lambda.
- L'implémentation du projet Library (celle qui n'est pas visible de l'extérieur) n'a pas de raison d'exister (mais il y a peut être d'autres informations qui je n'ai pas).

My two cents, comme on dit outre-atlantique...