Überprüfung, ob ein Objekt die IList<T>-Schnittstelle implementiert

Wie kann ich überprüfen, ob ein bestimmtes Objekt die Schnittstelle IList<T> implementiert? Dabei soll egal sein, was T für ein Type ist.

Gibt es eine ähnliche Methode wie:

if(myObject is IList) { ... }

?

Danke.

Gruß
SlEasy

Hallo SIEasy

Mit deinem Code sollte das funktionieren.

Gruss Peter

Hallo Peter Bucher,

da IList<T> von IList abgeleitet ist, würde die Abfrage zwar für jede IList<T> wahr sein, aber aber wenn die Abfrage wahr ist, würde das nicht zwangsläufig bedeuten, dass IList<T> implementiert ist.

Hallo SlEasy,

momentan sehe ich keinen anderen Weg als über Reflection. Das ist aber eher ein Zeichen dafür, dass man das nicht braucht, was du willst. 🙂 Warum denkst du, dass du es brauchst?

herbivore

Das wäre zu kompliziert, das hier auszuführen.

Über Reflektion ist es auch nicht einfach möglich. Aufrufe wie

if(typeof(IList<>).IsAssignableFrom(oPropertyDescriptor.PropertyType.GetGenericTypeDefinition()) == true) 

funktionieren zwar, aber nur, wenn oPropertyDescriptor.PropertyTypeGetGenericTypeDefinition() auch den Schnittstellen-Type IList<> zurückliefert. Sobals aber oPropertyDescriptor.PropertyTypeGetGenericTypeDefinition() nicht typeof(IList<>) sondern typeof(List<>) ist, funktioniert es nicht.

Hallo herbivore

Original von herbivore
da IList<T> von IList abgeleitet ist, würde die Abfrage zwar für jede IList<T> wahr sein, aber aber wenn die Abfrage wahr ist, würde das nicht zwangsläufig bedeuten, dass IList<T> implementiert ist.

Hmm, das verstehe ich jetzt nicht ganz.
Eine Schnittstelle ist muss / wird immer implementiert, wenn man davon ableitet, ausser man implementiert diese Schnittstelle zuvor schon in der Basisklasse, meinst du diesen Fall?

Gruss Peter

Nein, er redet davon, dass wenn ein Objekt die Schnittstelle IList implementiert, dieses nicht zwangsläufig die Schnittstelle IList<T> implementiert.

http://der-albert.com/archives/54-Pruefen-auf-generisches-Interface-in-.NET-2.0.html

Aber treiben wir das mal weiter: Wie finde ich raus, welche Bedingungen das Interface an den Typ stellt (where). Spätestens hier merkt man halt, dass man es mit einer typisierten Sprache zu tun hat. Dies hat auch Nachteile, wie man an diesem Beispiel sieht.

In Schönheit sterben wird man mit einer Lösung zu diesem Problem (siehe oben) jedenfalls nicht. Elegant wird das nie.

Oder vielleicht ein ganz anderer Weg:

http://www.codeproject.com/cs/library/nduck.asp?df=100&forumid=351497&exp=0&select=1740188

da IList<T> von IList abgeleitet ist

Stimmt nicht. IList<T> ist von ICollection<T>,IEnumerable<T> und IEnumerable abgeleitet. Und wenn man jetzt eine Schnittstelle macht, die IList und IList<T> erbt, dann kann man wichtige Eigenschaften wie Count nicht mehr verwenden, da diese sowohl in IList als auch in IList<T> definiert sind.

Dank expliziter Interface-Implementation sind sich überschneidende Membernamen doch gar kein Problem 🤔

Ja, klar, das Problem ist nur, dass du dich jedes Mal beim Aufruf eines auf diese Weise doppelt definierten Members entscheiden musst, welchen du jetzt meinst (IList oder IList<T>). Das ist unübersichtlich und stiftet Verwirrung.

Du musst dich nicht entscheiden. Du arbeitest einfach mit dem, was du siehst. Was du nicht siehst, geht dich in der Regel auch nichts an. Wenn du IList<T> siehst, benutze das, wenn du IList siehst, benutze das, wenn du die konkrete Klasse siehst, benutze was die dir anbietet.

Public Interface IBothList<T> : {IList<T>,IList} {}

und

IBothList<String> l
int i=l.Count    //geht nicht weil doppelt definiert
int i=(IList)l.Count  //geht, aber ich muss mich halt entscheiden

wenn man mit konkreten Klassen arbeitet passiert das natürlich nicht, aber so...

Hallo onlinegurke,

Stimmt nicht. IList<T> ist von ICollection<T>,IEnumerable<T> und IEnumerable abgeleitet.

du hast Recht. Ich hatte mich davon leiten lassen, dass IEnumerable<T> von IEnumerable abgeleitet ist und hatte daraus fehlgeschlossen, dass alle generischen "Collection"-Interfaces von den zugehörigen nicht generischen Interfaces abgeleitet sind.

//geht nicht weil doppelt definiert

Wenn du von zwei Interfaces erbst, die den gleichen Member haben, hast du sicher Recht. Aber es ging ja darum, dass IList<T> von IList abgeleitet wäre und dann könnte man die Definition von den beiden Interfaces so gestalten, dass keine Mehrdeutigkeiten auftreten. Bei IEnumerable<T> bzw. IEnumerator<T> gibt es die Probleme mit Mehrdeutigkeiten ja auch nicht, obwohl die jeweils von den entsprechenden nicht generischen Interfaces abgeleitet sind.

Davon abgesehen hast du ja gezeigt, wie man mit Mehrdeutigkeiten umgehen kann, wenn sie denn eben doch auftreten. Also wären selbst Mehrdeutigkeiten kein Argument gegen die Ableitbarkeit.

herbivore