Z.B. kann ich prüfen, ob ISerialization unterstützt wird und das Objekt dann serialisieren.
Wenn IOrganic unterstützt wird kann ich DoDestroying(1) aufrufen usw.
Dass Supports schlecht sein soll, erschließt sich mir irgendwie nicht.
In einem solchen Fall würdest du aber ein nicht referenzgezähltes Objekt übergeben und dort auf IWasAuchImmer überprüfen, um dann damit was zu machen und nicht ein bestimmtes Interface. Ich bezeichne solche Objekte mal als Datenobjekte. Sie könnten bestimmte Aspekte über Interfaces zur Verfügung stellen (wobei ich das auch nicht für das Gelbe vom Ei halte, dazu unten mehr).
Ich kann aber auch Interfaces als Services übergeben (im Gegensatz zu Datenobjekten sind das Klassen bzw Interfaces, die irgendwelche Arbeit erledigen) und da sollte man aufpassen, irgendwelche Annahmen darüber zu machen, welche Interfaces möglicherweise noch implementiert sind (Stichwort
http://en.wikipedia.org/wiki/Leaky_abstraction). 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).
Zu dem oben angesprochenen Punkt. Wenn Datenobjekte allerlei Interfaces implementieren, die dann irgendwas mit dem Objekt machen, handelt man sich sehr schnell Probleme mit dem SRP ein (das Objekt hält also nicht nur Daten, sondern Serialisiert sich, schreibt sich in die Datenbank, kann sich ausdrucken und vieles mehr). Zudem kommt es dann auch sehr schnell zu einer vermischung von verschiedenen Layern, die nix miteinander zu tun haben. Ich will damit nicht sagen, dass man das keineswegs machen sollte, aber man sollte aufpassen, welche Funktionalität man damit zur Verfügung stellt und inwieweit man seine Datenobjekte dann von anderen Schnittstellen abhängig macht.