Ich muss mich mal outen: Seit vielen Jahren entwickle und pflege ich mit Delphi eine ziemlich umfangreiche Branchenanwendung (In House, neuerdings mehrere Standorte). Nach Ausflügen zu C# und PHP/Javascript bin ich doch immer wieder bei Delphi gelandet. Jetzt steht die Modernisierung vieler älterer Module an und ich beschäftige mich seit Tagen intensiv mit Interfaces. Bisher ein weißer Fleck auf meiner Delphi Landkarte.
Ja: Auch im Jahre 2016 AD gibt es es immer noch Entwickler die mit „plain old delphi objects“ coden.
Nun gehe ich mal davon aus, dass all‘ die Delphi-Gurus hier und anderswo nicht aus rein modischen Gründen und nicht erst seit gestern die Verwendung von Interfaces immer und überall bevorzugen sondern gute Gründe dafür haben.
Ich habe dazu mehrfach den Abschnitt in Nick Hodges Buch (Coding in Delphi) zu dem Thema gelesen. Ein großes Plädoyer für die Programmierung mit Interfaces. Weiterhin habe ich gegoogled was das Zeug hält und auch viele Beiträge hier im Forum durchgeackert. Ich habe mir selbst mal ein paar Interfaces gebastelt und damit gespielt. Lange Rede, kurzer Sinn: Ich glaube prinzipiell verstanden zu haben wie Interfaces funktionieren auch wenn ich einige hiesige Forumsbeiträge zum Thema keineswegs verstanden habe.
Bei vielen verstehe mitunter nicht mal über welches Problem geschrieben wird. Offensichtlich sind es jedoch manches Mal Probleme die man ohne Interfaces nicht hätte. Das „reference counting“ finde ich z. B. nach meinem derzeitigen Verständnis von interfaces gelinde gesagt sche.. ääh nicht gut.
Wie dem auch sei: Der Knackpunkt bei der Frage nach dem Einsatz von Interfaces ist für mich das „Warum“. Darauf habe ich nirgendwo eine befriedigende Antwort bekommen. Ich zitiere mal (ich hoffe, das ist OK) eine Passage aus dem Text von Nick Hodges, (Buch „Coding in Delphi“, Blog) aus dem Abschnitt
„Why Do You Want To Use Interfaces?“ um mein Problem zu verdeutlichen:
Zitat:
Nick Hodges, Blog Coding in Delphi
[...]Say you have a large system with different teams working on different major modules.* Those teams are responsible for providing functionality in their own modules, and thus they are responsible for the integrity and quality of the code in their modules.* Let’s say you are on the Widget team, and you need the Sprocket team to do something for you.* You go to the Sprocket guys and say “Hey, I need to add a few things in the Sprocket code so that we can do some Sprocket-type stuff in our Widget.”* The Sprocket guys are going to laugh at you – like they are going to let you poke around in their carefully crafted system!* No, instead, they will likely ask you want you need, build the functionality, and hand you some code with an interface and a factory for creating an implementation of that interface.* They aren’t going to let you anywhere near their code – but they are happy to let you have an interface into that code.* You get what you want – some Sprocket functionality – and they don’t have to expose anything more than an interface to you.* And later, if they completely re-architect their code, what do you care?* Your interface still works, even if they completely change the internal implementation.* That’s a sound way to develop, all made possible because of interfaces....
Das folgende Staement irritiert mich außerordentlich:
Zitat:
..Your interface still works, even if they completely change the internal implementation.* That’s a sound way to develop, all made possible because of interfaces.
Nochmal: „
...all made possible because of interfaces.“????? Das gilt so auch für Klassen. Warum soll das oben beschriebene Widget/Sprocket Problem durch Interfaces erst lösbar sein? Ich hantiere (wie viele andere) alltäglich mit Klassen, über deren Implementierung ich nichts weiß, nichts wissen will und auch nichts wissen muss. Das ist doch ein wesentliches Merkmal von klassischer
OOP.
Aber dann natürlich
Zitat:
If you choose not to embrace interfaces, then you are locking yourself out of new and effective programming frameworks and techniques.* Or, put another way, all the cool kids are doing interfaces, and you want to be part of the cool kid group, right?
Ja. ich will zu den coolen Kids gehören. Ich ahne, dass da was ist was ich nicht sehe. Und damit komme ich zum Schluss und zu einer konkreten Bitte: Kann mir irgendwer hier ein Beispiel, entsprechende Links oder Literaturempfehlungen posten denen ein durchaus erfahrener, aber mit Interfaces nicht vertrauter Entwickler entnehmen kann worin der Nutzen von Interfaces gegenüber einer „normalen“ Hierarchie aus (auch abstrakten) Klassen liegt. Was kann ich damit exklusiv tun? Und wenn nicht exklusiv, dann zumindest einfacher oder besser. Vermutlich sind all‘ die Beispiele die ich bisher gelesen habe zu trivial. Zu komplexe waren allerdings auch dabei. Ich erkenne einfach den Nutzen von Interfaces immer noch nicht. Lasst mich nicht dumm sterben!
Anything, carried to the extreme, becomes insanity. (Exilant)