[Dresden-pm] Frage zur Implementation von einer Schnittstelle

[Hans-Dietrich Kirmse]

Hallo Torsten, Steffen & Steffen,

ich bitte schon im Vorab um Entschuldigung, das ich als Gast (in 
Thüringen gibt es keine Perl-Mongers Gruppe) und Laie (beschäftige mich 
erst seit ca. 5 Jahren als Autodidact mit Perl) euren alternativen 
Vorschlag anzweifel und vielleicht fällt auf Grund meines Alters (noch 
10 Jahre bis zur Rente) der Groschen manchmal sehr langsam, aber ich 
kann mir einfach nicht vorstellen, dass OOP hier überhaupt als Lösung in 
Betracht kommt.

Am 30.10.2011 10:36, schrieb Torsten Knorr:
> Hallo Hans-Dietrich,
>
> auch wenn die Frage schon beantwortet scheint möchte ich noch folgenden
> Gedanken anhängen.
> Eine Schnittstelle in Perl zu Spezifizieren dürfe sich als schwierig
> erweisen da Perl eine typenlose
> Programmiersprache ist. Die Spezifizierung einer Schnittstelle setzt aber
> genau eine Solche
> Type-Überprüfung voraus.

Hier würde es im angegebenen Fall nur um Folgendes gehen: es würde um 
das Einbinden einer Funktion (Subroutine) gehen, die entweder gar kein 
Argument benötigt (es soll ja nur der Displayname gesetzt werden) oder 
noch besser, den alten Displayname entgegen nimmt = String.
Zurück gibt diese Funktion den neuen Displayname, also auch wieder einen 
String. Das ist m.E. also hier absolut kein Problem.

Weiterhin: da ich diese Schnittstelle selbst implementiere, sind *alle* 
Optionen offen. Ich könnte also z.B. vorgeben, wie das Modul/Paket und 
auch wie die Funktion heißt.

> Aus diesem Grund möchte ich Dich auf ein anderes
> Konzept zur Lösung
> des obigen Problems hinweisen.
>
> Kurz: OOP - Vererbung

ich habe (in Perl) noch nie OOP genutzt, wohl aber in Pascal/Delphi. 
Trotzdem: wie kann OOP ein Konzept dafür darstellen?

> Also eine Klasse mit abstrakten Methoden schreiben welche als Basisklasse
> dient. In den abgeleiteten
> Klassen kann dann jeder Programmierer seine eigene Implementierung der
> Methoden vornehmen.

Und dann? Dann muss diese Klasse ja wohl instanziert und das neue Objekt 
aufgerufen werden. Das bedeutet aus meiner Sicht doch wohl, dass das 
Hauptprogramm diesbezüglich angepasst werden muss - anders gesagt, das 
Hauptprogramm muss doch wissen, dass es jetzt diese neue Klasse 
verwenden soll.

damit wird dieser Addon-Entwickler gleichzeitig derjenige, der die 
aktuellste Version des eigentlichen Programms "erstellt" hat und nutzt. 
Wie geht das dann weiter? Der Entwickler des eigentlichen Programms 
(hier ich) erstellt eine neue Version. Nur in dem Fall, dass ich 
überhautp Kenntnis von diesem (vermeintlichen?) Addon habe, kann ich das 
berücksichtigen. Das hat aber doch wohl nichts mehr mit einer 
Schnittstelle für die angegebene Zielstellung (Add-on) zu tun.

Mal auf ein anderes Programm übertragen: wenn ein Addon-Entwickler von 
Firefox den Firefox so erweitert, müßten aus meiner Sicht dann alle 
Addons in das Projekt einfließen, ansonsten fliegen die bei jedem Update 
(erstmal) wieder raus.

> Wies geht wird von Damian Conway in
>
> "Objektorientiert Programmieren mit Perl"
>
> beschrieben. (in deutsch)

Das Buch kenne ich (noch) nicht. Habe aber das Buch "Perl - Best 
Practices" von Damian Conway und auch "Perl Hacks ..." mit D.C. als 
Mitautor. Obwohl das Buch aus dem Jahre 2000 ist, werde ich mir das Buch 
mal zulegen.

zu Moose: da ich in Perl noch nie objektorientiert programmiert habe, 
habe ich demzufolge auch noch nicht Moose genutzt. Aber ich verfolge im 
foo-Magazin sehr wohl das was zu Moose geschrieben wurde.

Trotzdem, selbst wenn ich OOP mit Perl könnte - m.E. wäre das hier nicht 
zielführend. Wenn ich falsch liege, dann klärt mich bitte auf.

Viele Grüße
Hans-Dietrich