D.h. ich bekomm ein IFoo übergeben und versuche dann über Supports noch IBar zu bekommen um damit was zu machen. Erstens hab ich ein Problem, dass ich der
API nicht ansehen kann dass man nicht nur IFoo braucht sondern möglicherweise auch noch IBar. Und zweitens haben ich somit eine implizite Abhängigkeit auf die Implementierung (wer stellt denn sicher, dass beide Interfaces von derselben Klasse implementiert werden).
Wobei das ja durch Supports nicht vorgeschrieben ist. Supports sagt ja nur, ob dieses Interface unterstützt wird und liefert gegebenenfalls einen Zeiger darauf zurück. Nirgendwo steht, daß dieses Interface von derselben Klasse implementiert sein muss wie das Ausgangs-Interface. Immerhin ist Supports die einzige Möglichkeit, sinnvoll mit einer polymorphen IInterfaceList zu arbeiten. Hinter jedem IInterface dieser Liste kann ein ganzer Schwanz von Klasseninstanzen stecken, die für die verschiedenen Interfaces zuständig sind, die man gerade abfragt, und wo die Instanzen bis zur Abfrage vielleicht noch gar nicht erzeugt sein müssen.
Mehr noch - bei passender Implementierung (Stichwort: TAggregatedObject und implements) muss die effektiv IFoo-implementierende Klasse ja gar nichts über IBar wissen. Es kommt doch am Ende nur darauf an, welches QueryInterface bei Supports aufgerufen wird.
Natürlich könnte man um von IFoo auf IBar zu kommen in IFoo auch eine Funktion einbauen, die das IBar zurückgibt, aber damit hat man wiederum eine Abhängigkeit von IFoo zu IBar geschaffen. Auch die Verlagerung in ein Über-Interface, das sowohl IFoo als auch IBar als Funktionen bereitstellt, ist m.E. nicht gerade erstrebenswert. Der Weg über Interface-Aggregation liefert im Endeffekt das gleiche, die Verwendung von Supports finde ich aber deutlich übersichtlicher. Ob ich dann nicht doch lieber beide Interfaces in einer Klasse implementiere kann dem aufrufenden Code dann aber egal sein.