Mailinglisten-Archive |
> From: Oliver Michalak <omich at werk01.de>@phpbar.de on 29.04.2004 11:27
ZE2
> > Meiner Ansicht nach nicht. Allerdings macht das auch keinen
> > Sinn, Eigenschaften und Methoden von bar und db in eine 3. Klasse
> > zu importieren.
> > Mit einem einigermaßen glücklichen und überlegten Design lässt sich
> > das einfach umgehen.
> Interessehalber: wie? Ich stoße recht häufig auf das Problem von
> unabhängig entwickelten und im Einsatz befindlichen Klassen (nicht nur
> in PHP), von denen dann mehrere für einen weiteren Einsatz
> zusammengeführt werden könnten...
Tja, das ist ne gute Frage und vom Anwendungsfall abhängig - irgendwie
bekommt man da im Laufe der Zeit ein bisschen Gefühl dafür. Ob das dann
wirklich der beste/richtige/theoretisch richtige Weg ist, bleibt dann
immer noch offen.
Angenommen du hast eine Anwendung, die eine Datenbankklasse und eine
Benutzerklasse hat. Die Anwendung ist z.B. ein Kalender.
class DB {
...
function DB() {
# Konstruktor, verbindet sich zur DB
}
....
}
class User {
var $oDb; # Ein gültiges Datenbank-Handle
function User(&$oDb){
# Konstruktor,
$this->oDb = $oDb;
....
}
}
class Calendar {
var $oDb;
var $oUser;
function Calendar(){
# Konstruktor
$this->oDb = new DB;
$this->oUser = new User(&$this->oDb);
}
function Show(){
...
}
...
}
Ich hoffe, der Gedanke kommt einigermaßen rüber :-)
> Gibt es (zu empfehlenswertem OOP-Design) ein Standardwerk/-buch?
Ich kenn leider keines
Grüße, Mathias
php::bar PHP Wiki - Listenarchive