-- schnipp --
In der objektorientierten Programmierung (OOP) vereinbaren Schnittstellen (engl. Interface) gemeinsame Signaturen von Klassen. Das heißt, eine Schnittstelle vereinbart die Signatur einer Klasse, die diese Schnittstelle implementiert. Das Implementieren einer Schnittstelle stellt eine Art Vererbung dar.

Die Schnittstelle gibt an, welche Methoden vorhanden sind (bzw. vorhanden sein müssen) und wie sie zu verwenden sind.
(wikipedia)
-- schnapp --
Das hatte ich gemeint.

Es gibt ja das OO-Prinzip "Trennung der Schnittstelle von der Implementierung". Gut, die Befolgung dieses Prinzips liegt zum grossen Teil beim Entwickler selbst, mit Perl lässt sich das vielleicht hinbekommen, aber es ist keine Verpflichtung, es gibt keinen Mechanismus, der etwas strikter darauf achtet.
Ich denke, zu einer Schnittstelle gehoeren doch auch Signaturen etc. Ja, Java ist nicht Perl, ist mir klar und das ist ja auch gut so :)

Interessant wäre doch aber zum Beispiel die Möglichkeit, falsche Benutzungen von Methoden nicht erst zur Laufzeit mitzubekommen sondern schon mit perl -c. Finde ich.

Tja, das setzt eine stark typisierte Sprache voraus - dann nimm halt eine!

Quote

... mitzubekommen sondern schon mit perl -c. Finde ich.

Oder Schreib dein kompletten Code immer in einem CHECK{} Block. ;)

----
EDIT:

Beziehungsweise kann man auch einfach eine Subroutine folgendermaßen definieren

Quote

sub default_color { die "Methode default_color muss definiert werden!" }

Im Konstruktor benutzt du nun diese Subroutine um dein hash zu füllen. Wurde die Subroutine nicht von der vererbten Klasse Überschrieben bricht dein Programm halt ab.

Oder du schreibst halt eine Subroutine _check_methods die dann die Methoden aufruft und ihre Rückgabewerte überprüft. Diese Methode kannst du dann ja im Konstruktor aufrufen.


Allerdings hält es niemanden davon ab _check_methods einfach zu überschreiben. Den ersten Fall würde ich machen. Den zweiten eher nicht. Ich persönlich sehe da auch zur Zeit (mit meinem bisherigen Wissen) kein Bedarf darin soetwas zu wollen.\n\n

<!--EDIT|sid burn|1158650646-->

Ich hatte mal versucht, so etwas nachzubilden. Es sind halt keine echten Interfaces und es ist eher hässlich.

Falsche Benutzung von Subroutinen kannst Du auch mit Perl 5 verhindern:

[quote=renee,19.09.2006, 09:13]Falsche Benutzung von Subroutinen kannst Du auch mit Perl 5 verhindern:[/quote]
Bei Funktionen ja, aber nicht bei Methoden.

[quote=nepos,18.09.2006, 16:40]Sowie ich das Class::Trait sehe, ist das eher eine Nachbildung der Properties, die bei Windows-Programmierung oft genutzt werden. Sieht mir nicht so recht nach Interfaces aus.[/quote]
Trait sieht schonmal ganz gut aus, aber leider funktioniert das angegebene Beipiel nicht. Und das ist nur für einen Methodenalias, nicht mal für REQUIRE. Das Require-Beispiel mach überhaupt nichts weiter...



Hier kommt nur:

Attempt to alias method (strVal) that is not in trait (TPrintable) at Loam.pm line 3

Hat jemand ein einfaches, laufendes Beispiel für:

-Die Klasse "Loam" definiert, dass es die Methode "breath" geben muss, implementiert aber nix.

-Die Klasse "Human" erbt von Loam, enthält sonst aber nix.

-Die Klasse Human wird via "use" einegbunden und nirgends verwendet. Via Compiletime soll im günstigsten Fall gemeckert werden, dass die Methode "breath" definiert werden muss.

Irgendwer eine Idee?

hast Du Dir mal den verlinkten Wiki-Artikel angeschaut?

Hmmm, schon mal nicht schlecht. Gibt es einen anderen Weg, an die definierten Methoden einer Klasse heranzukommen, außer über das Einlesen des Klassenquellcodes?

Ja, schau Dir mal den Quellcode von Devel::Cover, Pod::Coverage und Test::TestCoverage an...

Ich bevorzuge Class::Inspector, wurde speziell für diese Zwecke
geschaffen.