OOP auf instanz aus anderer Class zugreifen

[DanyGee]

hallo

ich habe eine db class die zur datenbank verbindet und mit der ich querys an die db schicken kann, usw.

ich erstelle ein instanz in der header.php

zudem hab ich eine user class, die ich ebenfalls in der header.php aufrufe.

wie kann ich jetz eine db abfrage über die klasse machen?
neue instanz erstellen in klasse?

danke für eure antworten

[Kropff]

class DB {...}
class User extends DB {...}
// header.php
$obj = new User(); 

Zum Beispiel. Hängt aber von deiner Modellierung ab.

Peter

[h3ll]

class DB {...}
class User extends DB {...}
// header.php
$obj = new User(); 

Zum Beispiel. Hängt aber von deiner Modellierung ab.

Was hat der User mit der Datenbank zu tun? Von so einer Ableitung ist einfach nur abzuraten.

[Kropff]

Mir ging es nur ums grundsätzliche Prinzip. Wenn jede Klasse Abfragen an eine Datenbank stellt, so wäre das unter Umständen bei einem kleinen Projekt eine Lösung. Auch wenn das alles Andere als sauber ist. Da ich aber die Modellierung nicht kenne, habe ich das einfach mal in den Raum geworfen. Als Denkansatz.

Peter

[AmicaNoctis]

Hallo,

du kannst bei der Instanziierung der User-Klasse das DB-Objekt an den User-Konstruktor übergeben (der muss dafür angepasst werden) und als privaten Member speichern. Jede User-Methode, welche die DB braucht, kann dann über z. B. $this->dbObject->... darauf zugreifen.

Gruß,

Amica

[Kropff]

du kannst bei der Instanziierung der User-Klasse das DB-Objekt an den User-Konstruktor übergeben (der muss dafür angepasst werden) und als privaten Member speichern. Jede User-Methode, welche die DB braucht, kann dann über z. B. $this->dbObject->... darauf zugreifen.

Auch wenn ich das auch nicht für sehr prickelnd halte. Ist aber Ansichtssache.

Peter

[AmicaNoctis]

Auch wenn ich das auch nicht für sehr prickelnd halte. Ist aber Ansichtssache.

Was hast du gegen das Delegationsprinzip? Wenn eine Klasse die externen Ressourcen einer anderen (nicht verwandten) Klasse braucht, ist das doch wesentlich besser als die auf Krampf voneinander abzuleiten.

Generell würde ich es aber nach dem MVC-Pattern aufbauen.

[Kropff]

Was hast du gegen das Delegationsprinzip? Wenn eine Klasse die externen Ressourcen einer anderen (nicht verwandten) Klasse braucht, ist das doch wesentlich besser als die auf Krampf voneinander abzuleiten.

Ist imho beides nicht so toll. Aber wie ich schon sagte, das ist Ansichtssache.

Generell würde ich es aber nach dem MVC-Pattern aufbauen.

Dito!

Peter

[PHP-Desaster]

Ist imho beides nicht so toll. Aber wie ich schon sagte, das ist Ansichtssache.

Viel mehr bleibt da dann aber auch nicht mehr an Möglichkeiten. Vererbung oder Zugriff auf Objekt. Was wäre deiner Meinung nach sauber?

[combie]

Vererbung baut eine "ist eine" Beziehung auf.
"User ist eine DB"
Hört sich nicht gut an.

Meine Wahl wäre entweder Übergabe per Konstruktor, oder per Setter.


Und wenn per Setter, dann auch gleich ein Interface "NutzeDB"

Interface NutzeDB
{
  function setDB(MeineDbKlasse $db);
}

class User implements NutzeDB
{
 protected $db=null;
 public function setDB(MeineDbKlasse $db)
 {
   $this->db = $db;
 }

// und so weiter
} 

1. Das ist eine saubere Nummer.
2. tuts gut in einer Factory und mit dem DI Pattern

Viel mehr bleibt da dann aber auch nicht mehr an Möglichkeiten.

Singleton
Aber das wollen wir ja auch nicht.
Zumindest ich nicht.
Aber besser/logischer als die vererbungs Variante.

[Kropff]

Viel mehr bleibt da dann aber auch nicht mehr an Möglichkeiten. Vererbung oder Zugriff auf Objekt. Was wäre deiner Meinung nach sauber?

Ich reiche (normalerweise) Daten vom Controller an ein Model weiter, dass dann Zugriff auf eine Datenbank hat. Also ganz einfach(!) gesagt:

class Controller -> Zugriff auf entsprechendes Model
class Model extends DB 

Aber so richtig toll finde ich das nicht. Ist nur einen Bauchgeschichte und ich suche nach Alternativen. Habe bisher nur keine gefunden. Nenn das einfach Ordnungswahn.

Peter

[AmicaNoctis]

Die saubere Variante wäre, dass die User-Klasse selbst nicht aktiv auf die DB zugreift, sondern sich durch den Controller (MVC) befüllen lässt.

[unset]

OffTopic:

---

Eigentlich gehört da ja noch so einiges zwischen. Denn User ist keine "Nutze DB" sondern viel mehr ein Record. Und ein Record ist eine Untermenge einer Tabelle ... während DIESE eine Untermenge der Datenbank ist. Und so sollte man das auch aufbauen. Und schupsdiwups hat man auch schon kapiert, was es mit diesen Modellen auf sich hat.

class DB {}

class Table {
     protected $_db;
}

class Record {
     protected $_table;
}

class User extends Record {
} 

Dahingehend googlet man am besten auch mal nach Law of Demeter.

---

[AmicaNoctis]

@unset: Der Ansatz ist zwar sauber, hat aber den Nachteil, dass man dann entweder zusätzlich noch eine Klasse UserTable braucht, die ihre Datensätze von der Klasse User instanziiert, statt von Record oder beim Instanziieren von Table den Klassennamen für die gewünschte spezialisierte Record-Klasse übergeben muss.

[unset]

Das ist ja ein lösbares Problem. Da kann man mit konventionen Arbeiten (Benamung der Klasse oder der Tabelle), mit hard-coded Properties oder einfach indem man das der Tabelle beim instazieren schon sagt.

Ich arbeite da mit Konventionen ... hatte ich ja schon mal angedeutet ... was den Vorteil hat, dass ich Table- und Record-Klassen im Normalfall gar nicht anlegen brauche sondern die ihre Parameter selbst ermitteln können. Erst wenn besondere Methoden gebraucht werden, muss ich die Klasse anlegen.

Und sauber muss es immer sein