Ja, ich sehe das Problem, was vor allem in diesem speziellen Fall die Erklärung angeht. (Wir sind allerdings beruhigenderweise nicht die Einzigen, die das bei Interface vs. abstrakte Klasse nicht hinbekommen.) Ich habe gestern knapp 400 Wörter für diesen Thread als Antwort geschrieben, die aber nicht abgeschickt, weil ich kein einsichtiges Beispiel für einen Fall hatte, in dem ich ein Interface verwenden würde. Ich glaube, die Notwendigkeit für Interfaces ist stark kontextabhängig. Deshalb halte ich
viele der vorhandenen Erklärungen für völlig unbrauchbar. (
Logger_MySQL *ist* ein
logger, die Klasse implementiert nicht lediglich auch die Funktionalität eines Loggers. Für mich klare Vererbung.)
Das
Beispiel in Peter Kropffs Tutorial ist grundsätzlich etwas brauchbarer gedacht, jedoch letztlich auch wenig überzeugend. Die Implementierung des Interfaces
Traummann (ich lese da: "verhält sich wie Traummann") in der Klasse
Mann macht *jeden* Mann zu einem Traummann. Deshalb die Frage: Was unterscheidet einen Traummann dann noch von einem Mann, wenn doch ausgeschlossen ist, dass es Männer gibt, die keine Traummänner sind? Und: Welche Klasse sollte das Interface
Traummann noch implementieren, die selbst kein
Mann ist beziehungsweise die auch nicht von
Mann abgeleitet ist? Wozu brauche ich ein Interface und eine Klasse, wenn ich doch nicht zwischen beidem unterscheiden kann? Wesentlich logischer wäre es,
Traummann von
Mann abzuleiten und ihn vielleicht ein Interface
IstHygienisch implementieren zu lassen.
PHP:
class Traummann extends Mann implements IstHygienisch {}
IstHygienisch ist ein Interface, das durchaus noch von anderen Klassen implementiert werden könnte, da es sich nicht einzig auf die Männer bezieht.
PHP:
class Traumfrau extends Frau implements IstHygienisch {}
Eine Funktion, die nun ein "hygienisches" Objekt verlangt, würde Instanzen von Traummann bzw. Traumfrau akzeptieren.
PHP:
function verarbeiteHygienischesObjekt(IstHygienisch $obj) {}
Dieses Beispiel krankt natürlich daran, dass es nicht ganz leicht ist, sich eine Anwendung für etwas auszudenken, das "hygienisch" ist, über das aber sonst keine weiteren Aussagen getroffen werden. Die Funktion könnte nur mit den Methoden arbeiten, die das
IstHygienisch-Interface definiert.
Zudem geht das Design davon aus, dass es sinnvoll ist, Männer und Frauen zu trennen und nicht zum Beispiel lediglich eine Klasse
Mensch mit den Feldern
geschlecht und
istHygienisch zu implementieren. Ob das günstig ist, lässt sich kontextlos ebenfalls nicht sagen.
* * *
Aber mal zu deinem Beispiel.
Gilles schrieb:
Klar ist ein interface eine Schnittstelle. Jedoch nicht für 2 völlig "verschiedene" Klassen. Die Klassen müssen ja die vorgegebenen Methoden und Attribute besitzen.
Sie müssen die vorgegebenen Methoden und Attribute *des gemeinsamen Interfaces* implementieren, brauchen aber sonst absolut nichts miteinander zu tun zu haben.
Ein gutes Beispiel dafür ist das Interface
IstSerialisierbar. Es besagt, dass sich ein Objekt in einen String überführen und aus einem String wieder rekonstruieren lässt (zur Übertragung oder Speicherung). Sowohl
Traummann als auch
Db_MySQLi können dieses Interface implementieren und somit diese Funktionalität gewährleisten.
Gilles schrieb:
In dem Datenbank-Fall würde man mit Interface nur erreichen, dass der Code modular ist und man einfach eine andere Datenbank einsetzen könnte ohne dass deine Logik etwas davon bemerkt.
[...]
Hauptsache er kennt zum Beispiel die Methode connect
Das ist bei Vererbung exakt dasselbe, wie ich in #7 (erstes Codebeispiel) dargestellt habe.
Ein Interface könntest du dann einsetzen, wenn du etwa so etwas machen wolltest:
PHP:
interface Db_Interface
{
public function connect($host, $user, $password, $db);
public function query($query);
}
abstract class Application
{
protected $_db = null;
abstract function renderPage($url);
public function setDatabaseHandler(Db_Interface $db)
{
$this->_db = $db:
}
public function getDatabaseHandler()
{
return $this->_db;
}
}
class MyApplication extends Application implements Db_Interface
{
public function connect($host, $user, $password, $db)
{
mysql_connect($host, $user, $password);
mysql_select_db($db);
}
public function query($query)
{
return mysql_query($query);
}
public function renderPage($url)
{
$db = $this->getDatabaseHandler();
$result = $db->query("SELECT content FROM table WHERE url = $url");
// ...
echo $content;
}
}
$app = new MyApplication();
$app->connect('localhost', 'user', 'password', 'db');
$app->setDatabaseHandler($app);
$app->renderPage('index.html');
MyApplication implementiert die notwendige Datenbankfunktionalität einfach selbst und verzichtet darauf, eine Instanz einer weiteren Klasse übergeben zu bekommen. Sie kann also auch als Datenbankklasse eingesetzt werden, obwohl sie eigentlich eine
Application ist. Sowas geht nur mit Interfaces.
* * *
Edit:
Ein externer DB-Adapter, der
MyApplication übergeben werden könnte, könnte so aussehen:
PHP:
<?php
interface Db_Interface
{
public function connect($host, $user, $password, $db);
public function query($query);
}
abstract class Db_Abstract implements Db_Interface
{
// Gemeinsam von allen DB-Adaptern nutzbarer Code
public function quote($value)
{
if (is_string($value)) {
return "'" . str_replace("'", "\\'", $value) . "'";
}
return (int) $value;
}
}
class Db_MySQL extends Db_Abstract
{
public function connect($host, $user, $password, $db)
{
mysql_connect($host, $user, $password);
mysql_select_db($db);
}
public function query($query)
{
return mysql_query($query);
}
}
error_reporting(-1);
$db = new Db_MySQL('localhost', 'user', 'password', 'database');
echo $db->quote("Hier ist ein 'Teststring'.");
Das Interface ist also gewissermaßen die Erweiterung des Vererbungskonzepts, um auch Klassen, die nicht Teil der Vererbungshierarchie sind, die Möglichkeit zu geben, entsprechende Fremd-Funktionalität zu implementieren.
Ob das erstrebenswert oder gar notwendig ist, hängt stark vom Kontext ab.
