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