[Erledigt] Wann ein Objekt übergeben und wann Vererben?

[Curcio]

Hallo zusammen,

in den schönen guten Büchern findet man ja immer so "praxisnahe" aber zumindest vorstellbare Beispiele wie z.B. die Klasse Porsche erbt von der Klasse Auto...

Nun hatte ich in der Vergangenheit ein Programm entwickelt, welches ich in 2 Klassen abstrahiert hatte.

1. Daten Erfassung
2. Daten Auswertung

Bei der Daten Erfassung wurden die für die Auswertung nötigen Werte erfasst. In der Auswertung wurde an Hand dieser Werte ein Vergleichswert "Rankingwert" zu anderen ähnlichen Datenstrukturen geschaffen.

Damals hatte ich es so gelöst, dass die Klasse Auswertung direkt von der Klasse Erfassung abgeleitet wird. Im Nachhinein erhielt ich jedoch die Erkenntniss, dass es wohl sinnvoller gewesen wäre, hätte ich der Klasse Auswertung einfach ein Objekt der Klasse Erfassung übergeben.

Nach wie vor ist mir jedoch noch nicht ganz klar, wann es Sinn macht von einer Klasse zu erben oder der neuen Klasse einfach ein Objekt zu übergeben?

Habt ihr hier eventuell ein gutes Beispiel an Hand einer PHP praxisbezogenen Anwendung?

Vielen Dank!

[Flor1an]

Dein Beispiel wäre ein Beispiel für übergeben von Objekten.

Vererbung ist dafür gut dass du bestimmte Codestücke nicht doppelt schreiben musst. Wenn du zwei verschiedene Klassen hast die verschiedene Dinge tun ABER bestimmte Funktionen oder Variablen oder sowas gemein haben. Dann kannst du eine Klasse machen die diesen gemeinsamen Code enthält und die Klassen die davon erben implementieren dann spezifischen Code.

Zum Beispiel könntest du ein Formularelement als Klasse darstellen. Du hast die Eigenschaften Name, Wert, default Wert. Diese Eigenschaften haben ALLE Formularelement gemeinsam. Dann gibts z.b. noch die Methoden "isEmpty" und "getValue" und "setDefaultValue".

Und dann willst du die einzelnen Formularelemente als Klassen darstellen. Z.B. eine Klasse für Textfelder, eine für Selectfelder, eine für Checkboxen und so weiter. Alle diese Klassen erben von der Basisklasse, somit hat jedes Formularelement shconmal diese wichtigen gemeinsamen Eigenschaften. Aber du kannst noch zusätzliche Eigenschaften und Methoden implementieren. Zum Beispiel bei der Selectbox der Wert für "size".

[Asipak]

Mit einer Vererbung konkretisierst du ein Objekt, indem du in der Klasse weitere Eigenschaften und Methoden definierst. Je weiter du in der Hierarchie nach oben gehst, desto allgemeiner musst du werden.

Unter einer Klasse Auswertung oder Erfassung kann ich mir jetzt nur schwer etwas vorstellen. Vermutlich denkst du noch zu prozedural. Jedenfalls hört es sich für mich nicht so an, als ob beide Klassen irgendetwas gemeinsam hätten. Vererbung würde sich daher wohl eher nicht anbieten.

[Chriz]

Vererbung ist dafür gut dass du bestimmte Codestücke nicht doppelt schreiben musst. Wenn du zwei verschiedene Klassen hast die verschiedene Dinge tun ABER bestimmte Funktionen oder Variablen oder sowas gemein haben.

Die Erklaerung finde ich nicht gut, weil sie nicht zwingend auf fuer Vererbung vorgesehenen Programmcode zutrifft, sondern viel mehr umfasst.

Vererbung musst du dir wie in der Biologie vorstellen, als Teil-/Untermenge/Spezialform. Immer wenn die Beziehung nicht mehr als "ist Teilmenge von" beschrieben werden muss, sondern nur mit "verwendet", solltest du keine Vererbung vornehmen.

Haeufiger Fehler:
User extends MySQL:
Der Benutzer ist Teilmenge von MySQL? ... oder anders: Eine Person ist eine Spezialform einer Datenbank? Sicherlich nicht. Es geht ja um die Gesamtheit der Eigenschaften und Funktionalitaeten. Macht eine Methode connect() oder query() der MySQL in einer User-Tabelle Sinn? Ne.

Schwierig wirds halt bei abstrakten Dingen wie eben deiner Datenerfassung. Aber Erfassung und Auswertung sind nicht vererbar untereinander. Sie verwenden ja nur die Daten des Vorgaengers weiter.

[nikosch]

[MOD: verschoben]

[ragtek]

Die Erklaerung finde ich nicht gut, weil sie nicht zwingend auf fuer Vererbung vorgesehenen Programmcode zutrifft, sondern viel mehr umfasst.

Vererbung musst du dir wie in der Biologie vorstellen, als Teil-/Untermenge/Spezialform. Immer wenn die Beziehung nicht mehr als "ist Teilmenge von" beschrieben werden muss, sondern nur mit "verwendet", solltest du keine Vererbung vornehmen.

Haeufiger Fehler:
User extends MySQL:
Der Benutzer ist Teilmenge von MySQL? ... oder anders: Eine Person ist eine Spezialform einer Datenbank? Sicherlich nicht. Es geht ja um die Gesamtheit der Eigenschaften und Funktionalitaeten. Macht eine Methode connect() oder query() der MySQL in einer User-Tabelle Sinn? Ne.

Schwierig wirds halt bei abstrakten Dingen wie eben deiner Datenerfassung. Aber Erfassung und Auswertung sind nicht vererbar untereinander. Sie verwenden ja nur die Daten des Vorgaengers weiter.

Was aber IMHO bei
User extends MySQL_DataObject
wieder anders ist, da es meiner Meinung nach dann eine Teilmenge von der DB Zugriffsebene ist...
Es kommt doch auf die Architektur an...

[nikosch]

Was aber IMHO bei
User extends MySQL_DataObject
wieder anders ist,

Sehe ich nicht so.

MySQL_DataObject extends MySQL_DB : ja-jain
User extends MySQL_DataObject : nein

Eine Person ist keine Datenbank. Zugriff auf eine Datenmenge kann komponiert, User selbst können per Factory erzeugt werden.

[ragtek]

Wäre das eine Factory:

class user extends DataObject
{
protected $table = 'user';
..

public static function createFromId($id)
{
$user = new ...
//daten holen
return $user;
}
public function  isGuest()
{
return foobar;
}
} 

Weil das ist das was ich meine...

[nikosch]

Nö, nicht wirklich. Das hat im User-Objekt nichts verloren. Der User kann sich ja nicht selbst erstellen.

[ragtek]

Doch...
zB


$userdata = User::createFromId(4);
echo 'Benutzer '. $userdata->getName() . 'ist ' . $userdata->getStatus();


Aber wir weichen hier vom Thema ab finde ich

[nikosch]

Ja, das nennt sich Factorymethode, grundsätzlich gilt hier aber die selbe Kritik - Ein User ist keine Datenbank, ein Produkt (User) ist keine Fabrik (User Factory). Factorymethode ist auch schon so ein halbes Anti-Pattern.

[Curcio]

Hallo zusammen,

danke soweit für eure Antworten.

Klasse vererben
Also hätte ich eine Klasse User und wollte verschiedenen Usergruppen erstellen mit unterschiedlichen Rechten (-> Normalo kann sein Profil nicht ändern, Admin schon ...) würde ich von der Klasse User erben und beispielsweise die Klasse Admin erstellen. Das ist soweit richtig?

Objekt übergeben
Wenn ich eine Klasse User habe und dieser User für eine Klasse beispielsweise Schule benötigt wird. Würde ich das Objekt übergeben. Da nur die Instanz benötigt wird. Das dürfte auch soweit richtig sein?

Klasse User und Thematik -> neuen User erstellen
Nun weiß ich nicht ob ich die letzten Antworten richtig interpretiere. Wenn ich also eine Klasse User hab, wäre es falsch dieser Klasse eine Methode zu geben, welche einen neuen User erstellt? Beispielsweise in Form einer statischen Methode der Klasse? Ich denke genau für solche Aspekte gibt es statische Methoden?

Vielen Dank!

[nikosch]

Klasse vererben
Also hätte ich eine Klasse User und wollte verschiedenen Usergruppen erstellen mit unterschiedlichen Rechten (-> Normalo kann sein Profil nicht ändern, Admin schon ...) würde ich von der Klasse User erben und beispielsweise die Klasse Admin erstellen. Das ist soweit richtig?

Naja, auch das hinkt. Besser ist Vererbung auf Kontexte anzuwenden, die sich in Ihrem Verhalten unterscheiden, aber in ihrem „Äußeren“ ähneln. Eine Rechteverwaltung ist eigentlich eher ein Thema für sich, keine Eigenschaft eines Users.
Bsp: Ist Autofahrer eine Erweiterung von User? Schließlich ist das Hauptkriterium doch, dass er ein Autoobjekt besitzt, was ihn zum Autofahrer macht. Sicher käme man nicht auf die Idee, jetzt dem User Methoden wie Lenke(), StarteWagen(), KurbeleFensterRunter() und soweiter zuzuordnen. Man könnte jetzt argumentieren, ein Autofahrer müßte eine Fahrausbildung besitzen, das wäre dann allerdings ein sehr enger Kontext (rufeAutofahrwissenAb()), was i.A. nicht Zweck der Vererbung ist.

Nun weiß ich nicht ob ich die letzten Antworten richtig interpretiere. Wenn ich also eine Klasse User hab, wäre es falsch dieser Klasse eine Methode zu geben, welche einen neuen User erstellt? Beispielsweise in Form einer statischen Methode der Klasse? Ich denke genau für solche Aspekte gibt es statische Methoden?

Naja, wie gesagt, in meinen Augen ist Factory Method ein weit verbreitetes Pattern, aber irgendwo auch ein Anti-Pattern. Während echte Factories erweiterbar sind, kriegst Du bei Factory Method bereits bei der Ableitung der Klasse arge Probleme. Ebenfalls, wenn die Factory andere Ressourcen (DB) oder Objekte benötigt. Dann bekommst Du riesige Methoden-Parameterlisten und dergl.

[edit]
Ich lese gerade, dass Fabrik Methode im eigentlichen Sinne auch noch was anderes meint, auf das meine Kritik dann nicht mehr zutrifft: http://de.wikipedia.org/wiki/Factory_Method

[edit2]
Das Beispiel mit den Restaurants ist eigentlich recht vielsagend: http://de.wikipedia.org/wiki/Factory...iel_in_C.2B.2B

[Curcio]

Hallo nikosch,

danke für deine Antwort. Interessante Thematik.

[agrajag]

Ich finde Factory-Methoden eigentlich nicht schlimm. Mit PHP 5.3, late static binding und __callStatic würden sich da theoretisch schon coole Sachen basteln lassen.

MySQL_DataObject extends MySQL_DB : ja-jain
User extends MySQL_DataObject : nein

Sehe ich genau umgekehrt. Einfach mal den "ist ein"-Test machen:
User ist ein MySQL_DataObject. Jep, kann sein.
MySQL_DataObject ist eine MySQL_Db. Nein, definitiv nicht.