Edit
Malgré la réponse ci-dessous, je dirais que la meilleure solution est celle que la plupart des autres réponses pointaient. (Cela suppose que vous pouvez redéfinir les multiples classes qui implémentent les interfaces.) P>
Créer une interface qui hérite à partir de l'interfacea et d'interfaceb, puis pour toutes les classes qui implémentent des interfaces A et B, remplacez ces interfaces avec le nouveau. Avant: p> xxx pré> après: p> xxx pré> La mise en œuvre de FOO est alors assez triviale. Et, encore une fois, puisque vous ne savez pas à la compilation, quel type vous avez sur la main, vous pourrez peut-être simplement le déclarer comme p> xxx pré> fin d'exécution p>
Vous pouvez le faire en utilisant la réflexion, même si certains diront que ce n'est pas particulièrement "Nifty": P>
private void PrivateFoo(IInterfaceA objA, IInterfaceB objB)
{
if (!ReferenceEquals(objA, objB))
throw new ArgumentException("objA and objB must refer to the same object");
//... do your thing here
}
public void Foo(object someObj)
{
PrivateFoo((IInterfaceA)someObj, (IInterfaceB)someObj);
}
Quel type voulez-vous que ce soit après la distribution?
Vérifiez le concept de covariance de .NET Framework 4, cela peut aider, mais pour cela, vous devez également modifier la mise en œuvre.
Pouvons-nous avoir l'héritage des interfaces?
@CJBREW Eh bien, je suppose que ce sera un type qui n'existe pas, mais réalise les deux interfaces. Semblable à un type anonyme.
@Ramesh Oui, c'est l'autre solution que je pensais, mais pour diverses raisons, je ne voulais pas descendre cet itinéraire (bien que je doive l'avoir probablement!)
@ user751975 J'ai utilisé la variance CO-Contra dans d'autres projets qui utilisent C # 4.0 et je ne crois pas que cela résoudrait ce problème - mais merci pour l'idée
Pouvez-vous élaborer sur le scénario dont vous avez besoin? Je ne peux pas penser à un seul cas, vous en auriez besoin ...
@Daniel je veux appeler FOO si mon objet réalise les interfaces et la barre si elle réalise différentes interfaces. Le type que j'ai n'est pas suffisamment spécifique (disons son type
objet ) afin que je dois jeter avec les deux interfaces afin que je puisse transmettre mon objet dans la méthode.Dupliquer défini! Je n'ai pas vu cela dans la liste des questions similaires que je saisis la question. Bonne trouvaille, merci
Vous ne pouvez pas avoir un article qui est un poisson et une chaise simultanément.
@Lukas je ne vois pas comment ce commentaire ajoute à la discussion
@Lukas: Que voulez-vous dire avec votre commentaire?
@Richk: Veuillez consulter ma réponse mise à jour.
S'il n'y a pas de relation entre ces deux interfaces, iterfacea, iterfaceb vous ne pouvez pas faire ce que vous voulez. Qu'en souciez-vous du comportement de ces deux objets exprimés par des interfaces. Vous avez un problème d'interfaces ou de votre méthode est trop coupé (ne peut pas dire lequel avec ce minuscule extrait abstrait). Semblable, vous avez deux animaux domestiques, disons un poisson et un chien et vous voulez nourrir l'un d'entre eux, vous pouvez regarder leur comportement - les deux peuvent manger - ou le fait qu'ils soient des mammifères et qu'un mammifère peut manger.
@Lukas il y a une relation. Prenons votre exemple, j'ai deux interfaces, ibreathable et aménagée. Les deux chiens et les poissons réalisent ces deux interfaces et respirent à la fois et bougent de différentes manières. J'ai une méthode qui nécessite quelque chose qui est à la fois - disons qu'il est nécessaire d'appeler respirer chaque fois que nous bougeons, nous ne sortons pas de respiration et mourons. J'ai besoin de couler sur les deux types, mais pas spécifiquement de poisson et non spécifiquement chien car j'ai beaucoup d'animaux dans ma ferme.
@Richk "dis dire qu'il est nécessaire d'appeler respirer chaque fois que nous bougeons" C'est un comportement, définissez une nouvelle intégration (avec héritage) qui décrit le comportement souhaité. Il gardera la chose plus explicite et imo simple.