Klassen/Objekte

[Stonebreaker62]

Hallo,

ich nutze schon einige Zeit Klassen und Objekte, bin inzwischen aber unsicher, ob das, was ich da tue wirklich sinnvoll ist und keine Performanceprobleme zur Folge hat. Irgendwo in einem Tutorial habe ich gelesen, dass Klassen aus Eigenschaften bestehen und aus Methoden, die diese Eigenschaften manipulieren.

1. Wenn ich das so eng auslege, dann hat eine Methode zur Validierung eines Formulars in einer Klasse nichts zu suchen, weil diese ja keine Eigenschaften manipuliert. Genauso wenig hätte eine Methode zur Anzeige aller Kunden in einer Klasse kunde nichts zu suchen, weil diese ja auch keine Eigenschaften manipuliert. Richtig?

2. Wenn obige Aussage richtig ist, dann hole ich im Konstruktor der Klasse eine Tabellenzeile (z. B. aus einer Tabelle kunde) und schaufle die Felder in die Objektvariablen(Eigenschaften). Nun manipuliere ich die Werte (z.B. mit einer Methode ->setAdresse ($strasse, $plz, $ort) bzw. setKundenummer und schreibe danach die Werte mit einer Methode ->updateDB () zurück in die DB. Ist das so richtig verstanden? Für die Performance kann es ja nicht förderlich sein, wenn ich in setAdresse bzw. setKundenummer gleich einen Update auf die DB mache. Richtig?

3. Spricht etwas dagegen in einer Methode auf Superglobals wie $_GET ['strasse']zuzugreifen oder sollte man den Inhalt von $_GET zuerst in eine Klassenvariable mit $kunde->strasse = trim($_GET ['strasse']) übertragen und von dort dann in die DB schreiben?

4. Für die Performance sollte es doch förderlich sein, wenn man Klassen möglichst klein hält und besser mit vielen kleinen Klassen statt mit wenigen grossen arbeitet. Richtig?

Für einige kurze Tips wäre ich dankbar.

[TobiaZ]

1. Wenn ich das so eng auslege, dann hat eine Methode zur Validierung eines Formulars in einer Klasse nichts zu suchen, weil diese ja keine Eigenschaften manipuliert. Genauso wenig hätte eine Methode zur Anzeige aller Kunden in einer Klasse kunde nichts zu suchen, weil diese ja auch keine Eigenschaften manipuliert. Richtig?

Japp, das siehst du eigentlich richtig.

2. Wenn obige Aussage richtig ist, dann hole ich im Konstruktor der Klasse eine Tabellenzeile (z. B. aus einer Tabelle kunde) und schaufle die Felder in die Objektvariablen(Eigenschaften). Nun manipuliere ich die Werte (z.B. mit einer Methode ->setAdresse ($strasse, $plz, $ort) bzw. setKundenummer und schreibe danach die Werte mit einer Methode ->updateDB () zurück in die DB. Ist das so richtig verstanden? Für die Performance kann es ja nicht förderlich sein, wenn ich in setAdresse bzw. setKundenummer gleich einen Update auf die DB mache. Richtig?

Würde ich auch als Richtig sehen. Insgesamt ist die Frage, ob das Holen des Datensatzes im Kostruktor oder außerhalb der Klasse erfolgen sollte, aber IMHO ist beides eine Möglichkeit, zumal du ja auch aus der Klasse heraus updaten willst.

3. Spricht etwas dagegen in einer Methode auf Superglobals wie $_GET ['strasse']zuzugreifen oder sollte man den Inhalt von $_GET zuerst in eine Klassenvariable mit $kunde->strasse = trim($_GET ['strasse']) übertragen und von dort dann in die DB schreiben?

Ist beides IMHO falsch. Richtig wäre Kunde->setStrasse($_GET['street']); aufzurufen. Du merkst, du bist zum einen nicht davon abhängig, wie das Formularfeld heißt, und zum anderen kannst du neben trim() später auch noch andere Funktionen erweitern und musst dies nur einmal in der Klassendefinition tun und nicht mehrfach bei jeder Zuweisung von ->strasse;

4. Für die Performance sollte es doch förderlich sein, wenn man Klassen möglichst klein hält und besser mit vielen kleinen Klassen statt mit wenigen grossen arbeitet. Richtig?

Pauschal würde ich sagen: Ja. Es fördert zudem die Übersichtlichkeit und hoffentlich die Wiederverwendbarkeit. Wenn es nur um Performance geht, fährst du u.U. noch besser, wenn du ganz auf Klassen verzichtest.

Dass sollte so im großen und ganzen die weitläufige Meinung sein. 100%ig kann man es vermutlich nicht sagen, weil PHP nicht so wirklich die klassische oo Programmiersprache ist.

Für deine zwei Beispiele vom Eingang halte ich es z.B. oft so, dass ich eine Validierungs-Klasse zur Verfügung habe. Diese ist jedoch meist komplett statisch, wodurch es eigentlich nur noch eine Sammlung nützlicher Funktionen ist. Hat mit OOP nicht mehr viel zu tun, trotzdem lassen sich so Schmankerl wie Autoloading verwenden.

Bei der Kunden, bzw. einer Objekt-Klasse (Benutzer, oder sonstige DB-Einträge) macht es oft gar keinen Sinn, oo zu arbeiten. Zwar lassen sich die Objekte (von Natur aus) gut in einer Klasse abbilden, aber sie existieren halt viel zu kurz, als dass es lohnt, sie zu erstellen. Die Wiederverwendbarkeit geht meist gegen 0. Und warum sollte ich mir die Mühe machen, alle Kundendetails aus der DB zu holen, wenn ich die Zeile im nächsten Moment wieder aus der DB löschen will? new Kunde(13) holt die Kundendaten und Kunde->delete() löscht ihn.

Du siehst es ist ein schmaler Grat und in vielen Fällen Ermessenssache.

[ModestLife]

1. Wenn ich das so eng auslege, dann hat eine Methode zur Validierung eines Formulars in einer Klasse nichts zu suchen, weil diese ja keine Eigenschaften manipuliert. Genauso wenig hätte eine Methode zur Anzeige aller Kunden in einer Klasse kunde nichts zu suchen, weil diese ja auch keine Eigenschaften manipuliert. Richtig?

Japp, das siehst du eigentlich richtig.

Find ich überhaupt nicht. Eine Klasse kann doch ohne weiteres ein Formular repräsentieren? Und da sie dies kann, kann sie auch Methoden zur Validierung eines Formulars bereitstellen. Anderes Beispiel: Eine Coverter-Klasse die A nach B konvertiert. Die wird auch nicht viel mit ihren Eigenschaften machen, vermutlich ist sie sogar abstrakt und hat nur statische Methoden.

Ich finde die Aussage, eine Klasse stellt ausschliesslich Methoden bereit um ihre Eigenschaften zu verändern, komplett falsch.

[PHP-Desaster]

Mit der Datenbank kannst du sehr wohl sogar sehr schön OOP arbeiten. Guck dir zum Beispiel mal Propel an. Damit hast du die Möglichkeit, dir deine SQL-Skripte und deine Datenbankobjekte automatisiert generieren zu lassen und kannst anschließend ohne viel eigenem SQL-Code sehr bequem auf die Datenbank zugreifen.

[Stonebreaker62]

Schönen Dank für die ausführliche Antwort.

Auf das Holen aller Kunden-Daten im Konstruktor der Klasse kunde etc. werde ich wohl besser verzichten und dazu eine separate Methode holeDatenausDB bereitstellen.

Ist es denn sinnvoll, für jedes Tabellenfeld einer Kundentabelle eine Methode wie z. B. getAdresse bzw. setAdresse bereitzustellen, die jeweils nur diesen einen Wert (also die Adresse) aus der DB holt und mit setAdresse wieder zurückschreibt?

Das reduziert natürlich den DB Traffic, wenn in einem Dialog nur ein oder zwei Felder geändert werden müssen, erhöht ihn aber, wenn sehr viele Felder geändert werden müssen. Außerdem bekomme ich dann eine Inflation von Methoden, was wieder zu höheren Ladezeiten führt.

Performance-optimal wären wohl zwei Methoden, die genau nur die Werte aus der DB holen bzw zurückschreiben, die man manipulieren will. Wird allerdings etwas komplex, weil die SQL-Statements entsprechend manipuliert werden müssen. Hat das jemand zufälligerweise schon gelöst?

[h3ll]

Original geschrieben von Stonebreaker62
Ist es denn sinnvoll, für jedes Tabellenfeld einer Kundentabelle eine Methode wie z. B. getAdresse bzw. setAdresse bereitzustellen, die jeweils nur diesen einen Wert (also die Adresse) aus der DB holt und mit setAdresse wieder zurückschreibt?

Nein. Aber das macht Sinn:

class Person {
    private $adresse;

    public function getAdresse() {
        return $this->adresse;
    }

    public function setAdresse($adresse) {
        $this->adresse = $adresse;
    }
} 

[TobiaZ]

Eine Klasse kann doch ohne weiteres ein Formular repräsentieren? Und da sie dies kann, kann sie auch Methoden zur Validierung eines Formulars bereitstellen.

Da stimme ich dir durchaus zu. Ist halt nur die Frage, ob das ein klassisches Aufgabengebiet ist. Wie gesagt, gerade in PHP ist es oft Ermessenssache.

Eine Coverter-Klasse die A nach B konvertiert. Die wird auch nicht viel mit ihren Eigenschaften machen, vermutlich ist sie sogar abstrakt und hat nur statische Methoden.

Also ne Abstrakte Klasse wird erstmal gar nichts machen. Sobald sie dann aber wirklich in der Lage ist, Sachen zu konvertieren, trifft das schon wieder sehr auf die Manipulation von Eigenschaften zu. Wenn man dass dann static realisiert, ist das imho nur eine Vereinfachung des ganzen. Siehe auch das Beispiel der Validierungs-Klasse. Die verändert eingentlich noch weniger als die Konvertierungs-Klasse.

Mit der Datenbank kannst du sehr wohl sogar sehr schön OOP arbeiten. Guck dir zum Beispiel mal Propel an.

Dass man mit Propel sehr schön arbeiten kann, unterschreibe ich sofort. Allerdings handelt es sich ja so gesehen nur um einen Mapper, und verlagert die ganze DB-Aktion. Für den Code ists aber sicher sinnvoll.

Auf das Holen aller Kunden-Daten im Konstruktor der Klasse kunde etc. werde ich wohl besser verzichten und dazu eine separate Methode holeDatenausDB bereitstellen.

Wäre eine Möglichkeit, ist aber auch eine Zeile Code mehr. Dann solltest du auch noch berücksichtigen, wie du das Kundenobjekt in einer Kundenliste verwenden willst. Nehmen wir an, du möchtest alle Kunden anzeigen. Soll dann für jeden Kunden ein Query gefahren werden. (Hier hab ich übrigens selbst noch keine leicht gewichtige Lösung gefunden, Anregungen gerne)

Ist es denn sinnvoll, für jedes Tabellenfeld einer Kundentabelle eine Methode wie z. B. getAdresse bzw. setAdresse bereitzustellen, die jeweils nur diesen einen Wert (also die Adresse) aus der DB holt und mit setAdresse wieder zurückschreibt? Das reduziert natürlich den DB Traffic, wenn in einem Dialog nur ein oder zwei Felder geändert werden müssen, erhöht ihn aber, wenn sehr viele Felder geändert werden müssen.

Das schreiben sollte Imho erst ganz zum Schluss (oder nach Aufruf von writeChanges (könnte aus einem Interface stammen) erfolgen.

Außerdem bekomme ich dann eine Inflation von Methoden, was wieder zu höheren Ladezeiten führt.

__get() und __set()

Performance-optimal wären wohl zwei Methoden, die genau nur die Werte aus der DB holen bzw zurückschreiben, die man manipulieren will. Wird allerdings etwas komplex, weil die SQL-Statements entsprechend manipuliert werden müssen. Hat das jemand zufälligerweise schon gelöst?

Also IMHO können bei einer Kunden oder Personenklasse ja nicht so viele und vor allem nicht so große Daten anfallen. Da macht es dann auch nichts aus, unveränderte Felde noch mal an die DB zu senden.

Generell ist es aber auch kein Problem mit ner kleinen foreach-schleife nur die geänderten Felder in die SQL-Query aufzunehmen.

[Stonebreaker62]

Herzlichen Dank für Eure Antworten und Anregungen, vor allem natürlich an TobiaZ. Meine Verunsicherung hinsichtlich der Anwendung von Klassen ist total weg.

Finde das Forum einfach genial.

[jahlives]

Finde das Forum einfach genial.

OffTopic:

---

Und wieder ein zufriedener Kunde. Wenn TobiaZ noch 3 mehr kriegt dann bekommt er das tolle Messerset mit dem man ALLES schneiden kann zum Vorzugspreis. Einfach mal bei Berni durchklingeln

---

[Blackgreetz]

Sorry, dass ich nun deinen Thread mal mitnutze @ Stonebreaker62, aber es passt gerade hierzu

Ich hab ein ähnliches Problem und zwar hab ich ein Webftp geschrieben, der im Moment recht wenig Funktionen hat und eh überarbeitet werden muss.

Nun frag ich mich aber, ob es sinnvoll ist, dass ganze auf Klassen "umzuschreiben", weil es am ende ja wieder nur eine Sammlung von Funktionen wäre, die ich atm über get&switch aufrufe...

Also so wie die Sammlung von statischen Funktion zur Formularauswertung von Tobiaz^^

Wären dann zwar wohl 2 Klassen, 1x Ordner und 1x Files, wo alles recht statisch ist, aber anscheinend trotzdem sinnvoll?

mfg

[TobiaZ]

Also bezüglich WebFTP, so würde ich mir zumindest die Mühe machen und ne statische Klasse zu basteln, die kannst du in zukünftigen Projekten benötigen. Auch die FTP-Verbindung an sich, lässt sich sicher Wunderbar in einem Objekt new FTP(host, user, pass) abbilden. Ich würde es definitiv mal in Erwägung ziehen, wie gesagt, kannst du später sicher noch mal brauchen. Vorher mal gucken, ob PHP noch keine native Unterstützung (außer den FTP-Funktionen bietet.)

OffTopic:

---

@jah: ich glaub ich hab trotzdem ne negative Bilanz.

---

[Blackgreetz]

Okay, danke.

Zur FTP-Verbindung: Die wird nicht benötigt. Das Script selber liegt ja auf dem Server und dann wird per Dateiupload von PHP und den normalen Ordner-auslese Funktionen etc. das ganze aufgebaut.

Ist eben häufig bei kostenlosen Webspace der Fall, der sich meist über Werbung im WebFTP usw. finanziert.

mfg

[TobiaZ]

Zur FTP-Verbindung: Die wird nicht benötigt.

Ach so, ich dachte du hättest von webFTP gesprochen...

[Blackgreetz]

Dann nimm das p weg^^..
Ich weiß nur, dass es bei den Anbietern so genannt wird ... vlt, damit man als neuer User einen bekannten Begriff findet^^...

Ansonsten nenn ich es nun Dateibrowser, womit man aber wohl anfangs nicht soviel anfangen kann, oder?

Aber die eigentliche Frage haste trotzdem gut beantwortet...

Nun brauchste nur noch 2 zufriedene Kunden für dein Messerset^^