Man stelle sich eine Anwendung vor, die aus zwei Assemblies besteht. Die eine enthält ausschließlich Klassen, die zur Konfiguration dienen und etwa in die XML Repräsentation serialisiert werden. Als Beispiel eine Klasse StationInformation, die zu einem Fernsehsender alle Informationen für einen DVB Empfang beinhaltet (PIDs, um es konkret zu machen). Diese Assembly ist von nichts ausser .NET abhängig. Eine andere DLL implementiert einen DVB Zugriff über BDA und ist reichlich von diversen Bibliotheken abhängig. Natürlich auch von unserer ersten Assembly. In der zweiten Assembly gibt es etwa eine Klasse DVBHardware mit einer Methode UpdateStation, die eine StationInformation als Parameter erhält und die Empfangsdaten auf den aktuellen Stand bringt (etwa gibt es nur zeitweise einen Videotext wie bei KiKa).
Die Abhängigkeit der Assemblies zwingt nun erst einmal einen Anwender der Bibliotheken, die DVBHardware Instanzen ins Zentrum seines Denkens zu stellen: nur hier kann es Methoden geben, die beide Assemblies nutzen. Mit einer Extensionmethode läßt sich aber nun einfach eine Flexibilität erreichen, die eine natürlicher Sicht auf die Dinge erlaubt (eigentlich interessiert mich der Empfang eines Senders, die verwendete Hardware ist eigentlich zweitrangig): mit
public static void Update
(
this StationInformation station,
DVBHardware hardware
)
{
hardware.Update(station);
}
kann nun alternativ auch StationInformation.Update(hardware) aufgerufen werden. Aus Sicht des Anwenders, der beide Assemblies gleichzeitig verwendet und beim IntelliSense nicht so genau hinschaut sieht es fast aus, als würden sich die beiden Assemblies hier gegenseitig (zyklisch) referenzieren.
Wie dem auch sei und unabhängig davon, ob das Beispiel trägt: Extensionmethoden machen es beim Design von Bibliotheken einfacher, sich nicht schon früh auf eine Sichtweise festlegen zu müssen. Eine vollständig symmetrische Sicht ist zwar nicht immer notwendig und man kann es dabei auch leicht übertreiben, aber in Einzelfällen halte ich das für eine durchaus interessante Option – ausserhalb der trivialen Bedeutung, scheinbar abgeschlossene Klassen mit neuen Instanzmethoden erweitern zu können.
Happy Coding
Jochen