OOP - Datenkapselung und IDEs

[Laerik]

Moin,

ich beschäftige mich momentan mit der Datenkapselung in OO Anwendungen.
Ich habe momentan alle Klassen, die Daten aus der Datenbank representieren in eine Kategorie gepackt, die dann von der abstrakten Klasse DatabaseObject erben.
Die User Klasse bspw. holt im Konstruktor die Daten aus der Datenbank und übergibt die an die Elternklasse DatabaseObject, die dann via __get die Daten erreichbar macht.

Zum bearbeiten nutze ich eigene Editor Klassen, sprich die Datenklassen sollen readonly sein, was sie momentan durch den getter auch sind, nur gefällt mir das ganze nicht, denn die IDE Features (bspw. Autovervollständigung) leiden darunter.

Das IDE Problem lässt sich anscheinend mit @property im PhpDoc beheben, nur schlägt PhpStorm mir die Eigenschaften interessanterweise nur vor, wenn ich die @property Tags in der Elternklasse anlege, was etwas sinnfrei ist.

Mich würde interessieren, wie ihr die Datenkapselung macht und ob euch eine Lösung für das IDE Problem einfällt.
Einzelne getter Funktionen widerstreben mir für den Anwendungsfall etwas.

[nikosch]

die Daten aus der Datenbank representieren in eine Kategorie gepackt, die dann von der abstrakten Klasse DatabaseObject erben.

Das ist nicht gut. Datenobjekte sollten für sich stehen, egal, woher sie befüllt/wie sie erzeugt werden werden.

Guck Dir mal Factories an. Der kannst Du eine Datenbank via Dependency Injection übergeben.

[BlackScorp]

hier mal ein Beispiel von mir
https://github.com/Opentribes/Core/b...ntity/User.php

Das ist mein User Objekt, dem ist es egal woher es kommt, was damit passiert

https://github.com/Opentribes/Core/b...y/DBALUser.php

hier habe ich meinen Doctrine Repository die repository hat exakt die methoden die ich brauche um mir die Entity Objekte zu liefern, extern werden die entities manipuliert und in das Repository zurueck gelegt, nach dem Request wird dann den interne Speicher(array $users) mit der Datenbank synchronisiert.

Ich habe wenig magische dinge, stattdessen nutze ich lieber codegeneratoren von PHP Storm. die Entity zb. Ich erstelle einfach nur blin private eigenschaften, dann ALT+Insert -> getters setters und schon ist die entity generiert.

ich kann sogar sowas machen https://github.com/Opentribes/Core/b...ALUser.php#L23

kannst dann an der stelle https://github.com/Opentribes/Core/b...ALUser.php#L69 verfollstaendigung kriegen

[Laerik]

Danke erstmal für eure Antworten.

Ich bin noch nicht so weit mit OOP, daher verwende ich erstmal kein Framework (wobei ich anmerken muss, dass der queryGenerator von Doctrin sehr interessant aussieht @BlackScorp), sondern schaue mir verschiedene Frameworks an und versuche erstmal selber etwas funktionierendes auf die Beine zu stellen.

"Datenobjekte sollten für sich stehen, egal, woher sie befüllt/wie sie erzeugt werden werden."
Danke für den Hinweis, ich hatte da etwas falsch verstanden, in meiner Inspirationsquelle kann man nämlich auch eine andere Quelle übergeben, was ich schlichtwegeinfach übersehen hatte.

So ähnlich habe ich das jetzt bei mir auch aufgebaut:
https://github.com/WoltLab/WCF/blob/...ject.class.php

Ist das so ähnlich wie du das meintest, @Nikosch?
Man kann das Userobjekt dort ja auch mit anderen Daten befüllen.

Meine Problematik besteht momentan darin, dass ich die Umsetzung des getters im WCF (siehe Link oben) ungünstig finde, weil sie, wie bereits gesagt, die IDE Funktionen einschränkt.

Am einfachsten wären wohl einzelne getter, aber das fände ich nicht so toll, weil ich die Eigenschaften beim get Vorgang gar nicht weiter verändern will und ich bin kein Freund von vielen get Funktionen, die schlußendlich nur etwas returnen.
Gäbe es nicht eine Möglichkeit die IDE Funktion via @property wiederherzustellen? Bei mir funktioniert das irgendwie nur, wenn ich diese tags in die Beschreibung der Elternklasse reinsetze.

Vielen Dank im voraus.

[BlackScorp]

https://github.com/BlackScorp/logd/b...ry/PDOUser.php

es geht auch OHNE framework.. herrje ich dachte als entwickler sollte man abstraktes denkvermoegen haben

"Datenobjekte sollten für sich stehen, egal, woher sie befüllt/wie sie erzeugt werden werden."

damit meinte er dass deine klasse die die daten aus den spalten enhaelt, kein bezug zur datenbank haben soll, die soll eigenstaendig da stehen(Siehe meine Entity klasse ein simples objekt mit gettern und settern, keine ableitung )

und an der stelle hier https://github.com/BlackScorp/logd/b...er.php#L70-L74 waere zb eine Factory klasse angebracht, die factory muesste dann uber constructor der Repository uebergeben werden