Meine Bitte war, anhand von anspruchsvollem, realem Code konkret den Nutzen der dort verwendeten Interfaces aufzuzeigen und mir (und anderen) verständlich zu machen.
Das wird eher nicht passieren, da dieser Code meist "anspruchsvoll" ist. Dafür wird sich kaum einer die Zeit nehmen, oder gar Produktivcode posten.
Das Konzept muss man einfach verstehen und anwenden, dann hat man recht schnell selbst den anspruchsvollen Code.
Aber ein Beispiel, Du hast eine Klasse "XYZ", welche Daten eines Typs überprüft - sie kennt deren Struktur und Anforderungen. Diese Klasse (nennen wir sie auch einen Service), weiß nicht, was mit den Daten passiert, oder wo diese herkommen, bzw. gespeichert werden. Das wird durch andere Klassen erledigt. Zugriff auf diese Klassen wird Dir über Interfaces (Schnittstellen) erklärt. Wenn Du Daten lesen/speichern musst, dann holst Du Dir den gerade implementierenden Service heran und mittels der Schnittstelle kannst Du diese Daten laden und speichern. Dieses Klasse XYZ interessiert jetzt aber nicht, ob die Daten aus einer
XML Datei kommen, einer Datenbank oder aus dem TKitchenSink. Wozu auch, evtl. willst Du dem Anwender die Auswahl dazu überlassen. Am Ende muss aber jede Implementierung die Methoden zum Laden und Speichern anbieten und fertig ist's.
Und ein anderer Service implementiert die Verarbeitung der Daten (z.B. Druck, Darstellung, ...) und greift auf den Service (implementiert durch XYZ) zu. Dieser Service weiß jetzt, dass die Daten garantiert korrekt sind. Diesen interessiert nicht, wo diese herkommen, oder ob es diese überhaupt gibt. Aber wenn es diese gibt, dann sind die korrekt. Und wenn welche gespeichert werden sollen, dann wird sich XYZ schon darum kümmern, mich zu informieren, ob diese korrekt sind...
Dazu verwendet man i.A. Interfaces. Referenzzählung, autom. Freigabe, etc. sind nette Extras, aber nicht der Grund.
...
...
Daniel W.
Ich bin nicht zurück, ich tue nur so