parameter von interfaces in klassen richtig mit anwenden? - Seite 3

Arne Drews · 30.06.2009, 14:34

Ich habe auch den Sinn von interfaces erst nicht so recht wahrnehmen wollen.

Aber in bestimmten Umgebungen macht es tatsächlich Sinn.

Obwohl sehr knapp gehalten, fand ich diese kurze Zusammenfassung recht einleuchtend...
Da wird auch erklärt, daß man Konstanten in Interfaces definieren kann)

nikosch · 30.06.2009, 14:36

Zitat:

Das macht Sinn, wenn ein Wert gesetzt werden muss des optionalen Parameters durch den Aufruf der Methode.
Die Prüfung gegen Null erspart man sich somit. Es ist auch sinnvoller den default Wert im Interface zu definieren, als später durch alle Klassen zu gehen die das Interface implementieren und dort bei der Methode das handling des default Wertes anzupassen, wenn sich eine Änderung des default Wertes ergibt.

Veto! Dafür ist das Interface nicht gedacht. Sondern einzig, um die Zugriffsmethode zu definieren. Vorgabewerte sind nur nötig, wenn man variable Parametermengen erlauben will. Und genau dann machen imho Vorgabewerte keinen Sinn mehr, gerade, wenn es sich um solche Extreme wie Fahrrad-Auto-Traktor-Handwagen handelt. Genau dann sollte die Methode jeder Klasse Ihre eigene sinnvolle Vorgabe machen oder eine Prüfung anstellen. Man spart also nix.
Man darf ein Interface nicht als Vererbung begreifen. Auch nicht in dieser Hinsicht.

Wichtig ist die Erkenntnis, dass ein Interface Zugriffsmethoden vorschreibt.

Celli · 30.06.2009, 14:46

Zitat:

Man darf ein Interface nicht als Vererbung begreifen. Auch nicht in dieser Hinsicht.

Ich glaube wir reden aneinander vorbei. Ich bezeichne ein Interface nicht als Vererbung, da die definition in den head der Methode stattfindet. Da habe ich mich nicht klar genug ausgedrückt. Ich hatte mit den Änderungen des default Wertes gemeint, das alle Klassen die es implementieren allein durch eine Änderung im Interface auffallen würden, da die betroffenen Klassen nicht mehr funktionieren. Also leichter und schneller dieses zu ändern als zu suchen welche Klassen dieses Interface implementieren bzw. andere Programmierer dieses mitzuteilen.

Zitat:

genau dann machen imho Vorgabewerte keinen Sinn mehr, gerade, wenn es sich um solche Extreme wie Fahrrad-Auto-Traktor-Handwagen handelt

Wie bereits erwähnt:

Zitat:

Andersrum ist die Definition für alle Klassen die den Typ implementieren zwingend. Ich denke es ist von Fall zu Fall unterschiedlich.

nikosch · 30.06.2009, 14:50

Der letzte Satz ist unverständlich.

Ich sprach auch von „begreifen“. Ein Interface ist eine Schablone, was haben da konkrete Vorgabewerte drin zu suchen? Man weiss doch später gar nicht, was damit alles umgesetzt wird. Ein Vorgabewert macht nur dann einen Sinn, wenn er auch genautzt wird. Dazu ist imho aber eine Klasse zwischen Interface und Endobjekt besser geeignet, von der dann abgeleitet wird.

Ein Interface ist auch nicht zum Ändern gedacht. Und was Du als "Auffallen" bzeichnest, wäre unter Umständen eine Katastrophe.

Celli · 30.06.2009, 14:54

Ein Beispiel für ein default Wert wäre ein Standard Port wie 11211 für dem Memcache.

Zitat:

Ein Interface ist auch nicht zum Ändern gedacht. Und was Du als "Auffallen" bzeichnest, wäre unter Umständen eine Katastrophe.

Sicher, aber die deklaration eines Interfaces ist nicht immer beim ersten Code perfekt. Interfaces können sich ändern, genauso wie Klassen und ihre Handhabung.
Sicher würde man sie es "deprecated" setzen und später komplett ändern / ersetzen aber das sie als einmal gecodet und auf ewig haltbar gelten, das gibt es bei der Programmierung nicht.

nikosch · 30.06.2009, 15:31

Doch. Dann wird eben mit c&p ein neues Interface erstellt. Schon der Abwärtskompatibilität halber kannst Du nicht einfach ein Interface ändern. Nachhaltiger Code ist i.A. eher ein Merkmal guten Softwaredesigns.

Ein Interface sollte imho auch nicht zu spezifisch sein. Deshalb hat der Memcache und dessen Port wohl eher was in der Implementierung verloren. Ein Interface wäre dann vielleicht "Cachable" wit "write" und "load", ohne sich jedoch auf eine konkrete Caching-Art festzulegen.

mermshaus · 30.06.2009, 18:49

Mehr gefährliches Halbwissen und krude Interpretationen.

Zitat:

Zitat von Arne Drews

[Link zu Interface - php bar]

Die Beispiele, die dort vorgestellt werden, sind meiner Meinung nach mehr ein Fall für Vererbung. Die verschiedenen Realisierungen des "logger"-Interfaces sind nicht mehr als Erweiterungen eines "logger"-Grundkonzepts. Das zeigen auch sehr schön die Klassennamen: Logger_File, Logger_MySQL, ... Die Dinger sind alle "logger".

Das Interface könnte man einsetzen, wenn eine andere Klasse, die nicht in erster Linie "logger" ist, auch als "logger" eingesetzt werden können soll -- also quasi die Fähigkeit hat, als "logger" verwendbar zu sein.

Code:

interface logger
{
    public function open();
    public function write($msg);
    public function close();
}

class MyFrontController implements logger
{
    public function open() {}
    public function write($msg) {}
    public function close() {}

    public function displayPage() {}
}

In diesem Beispiel implementiert die Klasse MyFrontController die "logger"-Funktionalität, um auch als "logger" eingesetzt werden zu können, obwohl das eigentlich nichts mit ihrer Aufgabe als FrontController zu tun hat.

Aber was, wenn es Klassen wie Logger_File gibt, die die Methoden geschickter erben sollten, und auf der anderen Seite Klassen wie MyFrontController, die die Methoden geschickter implementieren sollten? Eine Klasse "logger" zum Vererben und ein Interface "logger" zum Implementieren? Klingt irgendwie redundant. -- Vielleicht ja so:

Code:

interface logger
{
    public function open();
    public function write($msg);
    public function close();
}

abstract class LoggerProto implements logger {}

class Logger_File extends LoggerProto
{
    public function open() {}
    public function write($msg) {}
    public function close() {}
}

* * *

Ich habe neulich mal versucht, zu erklären, was genau das "Iterator"-Interface (SPL) ist. Der leicht aktualisierte Text:

"Iterator" ist ein Interface, also eine Schnittstelle, die etwas über eine grundlegende Eigenschaft (im Sinne von "Verwendbarkeit") der Klasse aussagt. Hier eben, dass sie "iterierbar" ist, was sich praktisch unter anderem dadurch auswirkt, dass sie mit dem foreach-Konstrukt durchlaufen werden kann. Der Interface-Name irritiert etwas, er könnte eigentlich auch "Iterable" lauten (vgl. "Serializable").

Es gibt die mehr oder weniger treffende Analogie, dass Interfaces Adjektiven entsprechen. Das passt meiner Ansicht nach, leitet jedoch begrifflich etwas in die Irre. Häufig wird ein Interface dann eingesetzt, wenn man ausdrücken möchte: "Ein Objekt dieser Klasse kann sich wie ein Objekt einer anderen Klasse verhalten." Das ist der Schnittstellen-Gedanke. Es hat also die Eigenschaft, sich wie ein anderes Objekt verhalten zu können. Das wäre der Adjektiv-Gedanke.

Ein reichlich akademisches Beispiel, das man in der Praxis anders lösen würde:

Code:

class MyGuestbook implements ContentObject {}
class MyNavigation implements SidebarObject {}

Diese beiden Klassen sollen "darstellbar" sein. Die eine im Hauptteil der Seite, die andere meinetwegen in einer Seitenspalte. Da es also zwei Varianten von "darstellbar" gibt, die sich unterscheiden, wäre ein Interface "Displayable" nicht ausreichend und bevor man mit "DisplayableAsContentObject" anfängt, erzeugt man eben ein Interface "ContentObject", das "kann sich wie ein ContentObject verhalten" aussagt.

In diesem Fall würde man übrigens sicherlich darauf verzichten, überhaupt Interfaces einzusetzen, und Vererbung verwenden, da MyGuestbook logisch selbst zu den ContentObject-Objekten zählt und mit seiner Funktionalität nur einen Grundtyp von ContentObject erweitert. (Um die beliebten Fahrzeug-Analogien zu bemühen: Ein BMW ist ein Auto (mit allem, was ein Auto ausmacht), er kann sich nicht bloß auch wie eins verhalten.) Wenn MyGuestbook auch als WordpressObject (sagen wir mal, Wordpress stellt die Klasse bereit) genutzt werden können soll -- was nicht generell für jedes ContentObject gilt, weil unser Projekt nichts mit Wordpress am Hut hat -- dann wäre das ein Einsatzgebiet für ein Interface.

Das heißt zusammengefasst: In der Regel reicht Vererbung aus, eigene Interfaces definiert man eher selten. -- Ich habe lange Zeit den Fehler gemacht, "ist auch als Object verwendbar" (Interface) und "ist ein Object" (Vererbung) zu vermischen.

* * *

So wirklich gefällt mir der Erklärungsversuch noch nicht. Ich habe das Gefühl, mich ein wenig zu verrennen und den "Lenkbar"-Gedanken zu sehr außen vor zu lassen. *schulterzuck*

nikosch · 30.06.2009, 20:58

Ich würde den implements {interface} Gedanken als Vereinbarung beschreiben - Das Objekt/die Klasse verpflichtet sich, vom Interface vorbestimmte Methoden zu schaffen/anzubieten (zu implementieren). Als Gegenleistung ist dieser Teil der Klasse/des Objekts normiert, d.h. allein durch die kurze Interface-Deklaration vollständig beschrieben.
Je nach Normierungswillen kann man alle public Methoden eines Objektes vollständig auf ein oder mehrere Interfaces abbilden.

Die Interface-Implementierung sagt also nichts über die Zugehörigkeit oder Ableitung von einem anderen Objekt aus. Ein Interface sollte einzig Funktionalitäten beschreiben. Wenn man zur Überlegung kommt: "die Klasse braucht diese Methoden, passt aber thematisch nicht zum Interface" dann hat man letzteres falsch angelegt. Z.B. zu speziell oder zu allgemeingültig.

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Thema bewerten
Thema bewerten:

Ähnliche Themen
Thema	Autor	Forum	Antworten	Letzter Beitrag
Sinn und Zweck abstracter klassen und interfaces	litterauspirna	PHP Tipps 2009	8	13.06.2009 00:14
Mehrere Klassen verknüpfen	BlackJack01090	Software-Design	9	26.05.2009 20:43
wie Passwortschutz richtig anwenden?	ricardo	PHP Tipps 2009	13	19.01.2009 16:39
SOAP Server Parameter richtig zuordnen	Anotherone	PHP Tipps 2008	0	12.12.2007 11:23
Parameter überschreiben	Igäl	PHP Tipps 2006	8	04.06.2006 19:55
Parameter der mysql.exe richtig übergeben	bendigo	Datenbanken	5	24.11.2005 13:31
NOT EXISTS und NOT IN richtig anwenden		Datenbanken	6	11.08.2004 09:23

30.06.2009, 14:34
Arne Drews Erfahrener Benutzer Registriert seit: 22.04.2009 Beiträge: 3.486 PHP-Kenntnisse: Anfänger	Ich habe auch den Sinn von interfaces erst nicht so recht wahrnehmen wollen. Aber in bestimmten Umgebungen macht es tatsächlich Sinn. Obwohl sehr knapp gehalten, fand ich diese kurze Zusammenfassung recht einleuchtend... Da wird auch erklärt, daß man Konstanten in Interfaces definieren kann)


Mister Ad PHP Code Flüsterer Registriert seit: 21.08.2005 Beiträge: 4682 PHP-Kenntnisse: Fortgeschritten

30.06.2009, 14:50
nikosch moderatives Dielektrikum Registriert seit: 21.05.2008 Beiträge: 35.987 PHP-Kenntnisse: Fortgeschritten	Der letzte Satz ist unverständlich. Ich sprach auch von „begreifen“. Ein Interface ist eine Schablone, was haben da konkrete Vorgabewerte drin zu suchen? Man weiss doch später gar nicht, was damit alles umgesetzt wird. Ein Vorgabewert macht nur dann einen Sinn, wenn er auch genautzt wird. Dazu ist imho aber eine Klasse zwischen Interface und Endobjekt besser geeignet, von der dann abgeleitet wird. Ein Interface ist auch nicht zum Ändern gedacht. Und was Du als "Auffallen" bzeichnest, wäre unter Umständen eine Katastrophe. __________________ -- One pixel is still too big. Please make it smaller. ASAP. Initiative Mittelstand. Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers. --

30.06.2009, 15:31
nikosch moderatives Dielektrikum Registriert seit: 21.05.2008 Beiträge: 35.987 PHP-Kenntnisse: Fortgeschritten	Doch. Dann wird eben mit c&p ein neues Interface erstellt. Schon der Abwärtskompatibilität halber kannst Du nicht einfach ein Interface ändern. Nachhaltiger Code ist i.A. eher ein Merkmal guten Softwaredesigns. Ein Interface sollte imho auch nicht zu spezifisch sein. Deshalb hat der Memcache und dessen Port wohl eher was in der Implementierung verloren. Ein Interface wäre dann vielleicht "Cachable" wit "write" und "load", ohne sich jedoch auf eine konkrete Caching-Art festzulegen. __________________ -- One pixel is still too big. Please make it smaller. ASAP. Initiative Mittelstand. Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers. --

30.06.2009, 20:58
nikosch moderatives Dielektrikum Registriert seit: 21.05.2008 Beiträge: 35.987 PHP-Kenntnisse: Fortgeschritten	Ich würde den implements {interface} Gedanken als Vereinbarung beschreiben - Das Objekt/die Klasse verpflichtet sich, vom Interface vorbestimmte Methoden zu schaffen/anzubieten (zu implementieren). Als Gegenleistung ist dieser Teil der Klasse/des Objekts normiert, d.h. allein durch die kurze Interface-Deklaration vollständig beschrieben. Je nach Normierungswillen kann man alle public Methoden eines Objektes vollständig auf ein oder mehrere Interfaces abbilden. Die Interface-Implementierung sagt also nichts über die Zugehörigkeit oder Ableitung von einem anderen Objekt aus. Ein Interface sollte einzig Funktionalitäten beschreiben. Wenn man zur Überlegung kommt: "die Klasse braucht diese Methoden, passt aber thematisch nicht zum Interface" dann hat man letzteres falsch angelegt. Z.B. zu speziell oder zu allgemeingültig. __________________ -- One pixel is still too big. Please make it smaller. ASAP. Initiative Mittelstand. Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers. --