PDO Klassesen: Eine oder mehere Klassen?

[.MB]

Schönen Guten Morgen,

ich will über ein relativ Sicheres Login-System mit einer Datenbank kommunizieren.

Das Login integriert in einer Session Class habe ich fertig.

Absicht: Ich will noch passwort, user unnd userlevel in eine Datenbank reinschreiben, prüfen und auslesen, hashen uw.. Außedem möchte ich fest definirte tabellen Classes erstellen.

Frage: was spricht dagegen wenn ich das alles seperiert in Klassen schreibe?

Z.B.:

class password extends session { ... }

oder z.B.:

class table extends PDO { ... }

Was spricht dafür?

lg MB

PS: Ich hoffe ich nerve nicht, wenn ich mit einer gewissen permanenz frage.

[woodfighter]

Tach,

Absicht: Ich will noch passwort, user unnd userlevel in eine Datenbank reinschreiben, prüfen und auslesen, hashen uw.. Frage: was spricht dagegen wenn ich das alles seperiert in Klassen schreibe?

ich würde sagen ein User ist etwas, dass man als Klasse ansehen kann; ein Passwort eher nicht, das ist ja etwas, dass eh nur durchgereicht wird und man hat im wesentlichen nur zwei externe Methoden setPW und checkPW. Bei Userlevel hängt das davon ab, was damit gemeint ist: Wenn es tatsächlich nur ein Integer oder Enum ist (z.B. 0=admin, 1=mod, 2=user), würde ich das als Eigenschaft eines Users ansehen und eher nicht als eine Klasse implementieren; falls es aber eine kompliziertere Struktur abbildet, könnte das sinnvoll sein.

class password extends session { ... }

Das ergibt erstmal (ich weiß natürlich nicht, was da jeweils für Methoden und Eigenschaften dranhängen) keinen Sinn, ein Passwort ist keine Erweiterung einer Session.

Außedem möchte ich fest definirte tabellen Classes erstellen.

class table extends PDO { ... }

Ich kenne PHP und vorallem PDO nicht genug, in Java mit Hibernate wäre das (also Klassen, die einzelne Tabellen oder Views abbilden) etwas, das üblich ist; aber die PDO-Klasse sieht auch nicht wie etwas aus, dass durch eine Tabelle sinnvoll erweitert würde, PDO ist halt kein OR-Mapper sondern abstrahiert nur die Verbindung zur Datenbank. Ich vermute mal (kurze Suche bestätigt das auch), dass es auch ORM für PHP gibt.

mfg
Woodfighter

[pl]

hi,

Ich kenne PHP und vorallem PDO nicht genug, in Java mit Hibernate wäre das (also Klassen, die einzelne Tabellen oder Views abbilden) etwas, das üblich ist; aber die PDO-Klasse sieht auch nicht wie etwas aus, dass durch eine Tabelle sinnvoll erweitert würde, PDO ist halt kein OR-Mapper sondern abstrahiert nur die Verbindung zur Datenbank. Ich vermute mal (kurze Suche bestätigt das auch), dass es auch ORM für PHP gibt.

Meine Antwort in Perl wäre tie(%user, 'User') womit der Zugriff auf die Attribute wie bei einem ganz normalen Hash erfolgt und mit tied(%user)->write auch Methoden aufgerufen werden können.

Ebenso handhabe ich auch meine %SESSION als eine an eine Klasse gebundne Variable. Im Destruktor meines Framework-Objekts wird tied(%SESSION)->write aufgerufen, womit SessionDaten persistent werden.

Eine Referenz auf %SESSION liegt als Attribut in der FW-Instanz.

[.MB]

Hallo woodfighter,

ich würde sagen ein User ist etwas, dass man als Klasse ansehen kann; ein Passwort eher nicht, das ist ja etwas, dass eh nur durchgereicht wird und man hat im wesentlichen nur zwei externe Methoden setPW und checkPW.

ok bezogen auf deine genannte User Class???

Bei Userlevel hängt das davon ab, was damit gemeint ist: Wenn es tatsächlich nur ein Integer oder Enum ist (z.B. 0=admin, 1=mod, 2=user), würde ich das als Eigenschaft eines Users ansehen und eher nicht als eine Klasse implementieren;

Ja hatte ich vor. Sorry dass das nicht rübergekommen ist.

falls es aber eine kompliziertere Struktur abbildet, könnte das sinnvoll sein.

nein eine einfache struktur, jenachdem was man unter einfach bezeichnet.

Ich kenne PHP und vorallem PDO nicht genug

Nur die OOP Methodik und meines wissens nach ist mysql ähnlich wie pdo das nur 'oben draufgesetzt ist' nur das eben nicht OOP ist. Bin aber leider noch zu neu.

lg MB

[woodfighter]

Tach,

ich würde sagen ein User ist etwas, dass man als Klasse ansehen kann; ein Passwort eher nicht, das ist ja etwas, dass eh nur durchgereicht wird und man hat im wesentlichen nur zwei externe Methoden setPW und checkPW.

ok bezogen auf deine genannte User Class???

ja

Ich kenne PHP und vorallem PDO nicht genug

Nur die OOP Methodik und meines wissens nach ist mysql ähnlich wie pdo das nur 'oben draufgesetzt ist' nur das eben nicht OOP ist. Bin aber leider noch zu neu.

Wie meinen?

mfg
Woodfighter

[MB]

Hallo Woodfighter,

Ich kenne PHP und vorallem PDO nicht genug

Nur die OOP Methodik und meines wissens nach ist mysql ähnlich wie pdo das nur 'oben draufgesetzt ist' nur das eben nicht OOP ist. Bin aber leider noch zu neu.

Wie meinen?

Ich hab dich so verstanden, das du selbst erklärt hast, das du in php und grade pdo kein profi wärest. Ich nehme stark an in anderen OOP Programmiersprachen. Da hab ich gemeint, das es nicht so wichtig ist. Mir geht es nur um die Klassen und die Datenbank egal ob mySql, oder sqli usw.

Ist deine Frage beantwortet?

Grüße MB

[woodfighter]

Tach,

Ich hab dich so verstanden, das du selbst erklärt hast, das du in php und grade pdo kein profi wärest.

jup, sonst bekommt @Sven Rautenberg noch irgendwann ein schlechtes Gewissen, weil er mich ständig korrigieren muss ;-)

Ich nehme stark an in anderen OOP Programmiersprachen.

Profi im Sinne von andere haben mich schon dafür bezahlt, sicher nicht im Sinne von Virtuose, aber ja ich kenne die Spezifika von Javas OOP sicher besser als die von PHP.

mfg
Woodfighter

[pl]

Machs nicht zu kompliziert. Mein Vorschlag wäre eine Klasse User und wenn einer angemeldet ist, wird eine Instanz erstellt: Ein erfolgreiches Login ruft den Konstruktor auf.

Die Instanz führt dann Methoden aus wie $user->update('Vorname','Neuer Vorname') usw. und die Mehode $user->logout() löscht einfach den Eintrag in der Sessiontable.

Abstrahiere die Datenhaltung vom Code. In Fakt taucht das PDO-Objekt gar nicht mehr auf in deinem Code weil ein austauschbarer Layer dahintersteckt welcher im einfachsten Fall als Attribut in der User-Instanz vorhanden ist.

[.MB]

Hallo pl,

Abstrahiere die Datenhaltung vom Code. In Fakt taucht das PDO-Objekt gar nicht mehr auf in deinem Code weil ein austauschbarer Layer dahintersteckt welcher im einfachsten Fall als Attribut in der User-Instanz vorhanden ist.

habe ich schon gemacht ;) - wenn ich dich rictig verstanen habe. mir gehts nur um den weiteren verlauf meiner noch zu erstellenden klassen

schöne grüße MB

[pl]

hi MB,

habe ich schon gemacht ;) - wenn ich dich rictig verstanen habe. mir gehts nur um den weiteren verlauf meiner noch zu erstellenden klassen

schön ;)

Vielleicht kann ich dich ja irgendwann einmal für die Fabrikmethode begeistern, Achtung: Fabrikmethode im Sinne der Herangehensweise.

[.MB]

hi pl,

Vielleicht kann ich dich ja irgendwann einmal für die Fabrikmethode begeistern, Achtung: Fabrikmethode im Sinne der Herangehensweise.

klingt gut :). sehr gern.

Schöne Grüße mb

[pl]

hi MB,

Vielleicht kann ich dich ja irgendwann einmal für die Fabrikmethode begeistern, Achtung: Fabrikmethode im Sinne der Herangehensweise.

klingt gut :). sehr gern.

Das machen wir aber nicht hier in diesem Forum.

[MB]

ok, aber ich muss erstma mein projekt durch bekommen um ne halbwegst akzeptable note zu bekommen. Ich tu mich sehr schwer mit der Kommunikation, gerade in der gesamten Ausbildung. Aber es wird sich sicherlich Zeit finden, wo ich auf ein Angebot zurückgreifen werde ;-).

LG MB

[1unitedpower]

ok, aber ich muss erstma mein projekt durch bekommen um ne halbwegst akzeptable note zu bekommen. Ich tu mich sehr schwer mit der Kommunikation, gerade in der gesamten Ausbildung. Aber es wird sich sicherlich Zeit finden, wo ich auf ein Angebot zurückgreifen werde ;-).

Dieses Forum ist ein Hort der freien Wissensvermittlung, dabei werden auch schonmal Fehler begangen. Diese Fehler bleiben hier selten unkommentiert und rufen die Kritik anderer Forenteilnehmer auf den Plan. Wer dieser Kritik mit sachlicher Argumentation, Ergebnissoffenheit und Selbstreflektion begegnet muss sich davor nicht fürchten und wird letztlich davon profitieren. Wenn jemand der öffentlichen Kritik entfliehen will, mit der er sich in diesem Forum konfrontiert sieht, dann ist das unter Umständen ein starkes Warnsignal und nicht nur positiv zu bewerten.

[MB]

nabend 1unitedpower,

Dieses Forum ist ein Hort der freien Wissensvermittlung, dabei werden auch schonmal Fehler begangen. Diese Fehler bleiben hier selten unkommentiert und rufen die Kritik anderer Forenteilnehmer auf den Plan.

Deswegen bin ich auch hier und werde weiter hier sein.

Wer dieser Kritik mit sachlicher Argumentation, Ergebnissoffenheit und Selbstreflektion begegnet muss sich davor nicht fürchten und wird letztlich davon profitieren.

Du sagst es!

Wenn jemand der öffentlichen Kritik entfliehen will, mit der er sich in diesem Forum konfrontiert sieht, dann ist das unter Umständen ein starkes Warnsignal und nicht nur positiv zu bewerten.

Da gebe ich dir sehr recht und Danke für den rat. Ich sehe das in dieser Situation aber nicht.

LG MB

[pl]

Achso, Du bist nur wegen Deiner Ausbildung hier. Erfahrungsgemäß wird da heutzutage nur Müll vermittelt der mit praxisnaher Programmierung gar nichts zu tun hat. Und sieh da, das erklärt auch Einiges was Deine Herangehensweise anbetrifft.

Da kann ich Dir nur Eines mit auf den Weg geben, falls Du ernsthaft vorhast Programmierer zu werden: Finde Deinen eigenen Weg. Programmieren ist ein Handwerk, das kann niemand vermitteln, das muss jeder selbst erlernen. Gerade in Sachen OOP versagen herkömmliche Lehrmodelle vollends.

Mit viel Glück hatte ich damals die richtigen Dozenten, die richtigen Bücher und Meister der alten Schule, die mir sehr praxisnah die Freude am Programmieren sehr nachhaltig vermittelten.

[Matthias Apsel]

Hallo pl,

Achso, Du bist nur wegen Deiner Ausbildung hier. Erfahrungsgemäß wird da heutzutage nur Müll vermittelt

Aha. Du musst es ja wissen.

Programmieren ist ein Handwerk, das kann niemand vermitteln, das muss jeder selbst erlernen.

Das könnte ich unterstützen. Vor allem, was Kreativität und dergleichen betrifft.

Gerade in Sachen OOP versagen herkömmliche Lehrmodelle vollends.

Aha. Nenn mir zwei.

Bis demnächst
Matthias

[pl]

Aha. Nenn mir zwei.

OOP Blüten, siehst doch, was dabei herauskommt. Und die Lehre von der Vererbung riecht nach Fisch ;)

PS: Das Niveau hier im Forum ist mächtig gesunken.

[woodfighter]

Tach,

Abstrahiere die Datenhaltung vom Code. In Fakt taucht das PDO-Objekt gar nicht mehr auf in deinem Code weil ein austauschbarer Layer dahintersteckt welcher im einfachsten Fall als Attribut in der User-Instanz vorhanden ist.

eine Datenbankverbindung als Attribut eines Users? Selbst wenn da noch ORM dazwischen käme, fände ich das zum User gehörende Datenbank-Objekt als Attribut des Users sehr befremdlich.

mfg
Woodfighter

[pl]

Tach,

Abstrahiere die Datenhaltung vom Code. In Fakt taucht das PDO-Objekt gar nicht mehr auf in deinem Code weil ein austauschbarer Layer dahintersteckt welcher im einfachsten Fall als Attribut in der User-Instanz vorhanden ist.

eine Datenbankverbindung als Attribut eines Users? Selbst wenn da noch ORM dazwischen käme, fände ich das zum User gehörende Datenbank-Objekt als Attribut des Users sehr befremdlich.

Es taucht nur in den Methoden auf. Die Attribute eines Users sind völlig frei vom technischen Hintergrund. Wenn ich für sowas ein ORM einsetze ist der User ein reines Datenobjekt, also nur ein Array.

[woodfighter]

Tach,

Wenn ich für sowas ein ORM einsetze ist der User ein reines Datenobjekt, also nur ein Array.

Was das dann noch mit OOP zu tun hat, erklärst du dann aber besser der nächsten Wand statt hier.

mfg
Woodfighter

[pl]

Tach,

Wenn ich für sowas ein ORM einsetze ist der User ein reines Datenobjekt, also nur ein Array.

Was das dann noch mit OOP zu tun hat, erklärst du dann aber besser der nächsten Wand statt hier.

Geht der Pöbel schon wieder los? Meine Antwort ist tie(%user); und das Binden einer Variablen an eine Klasse ist sehr wohl OOP, aber hallo!

[woodfighter]

Tach,

Wenn ich für sowas ein ORM einsetze ist der User ein reines Datenobjekt, also nur ein Array.

Was das dann noch mit OOP zu tun hat, erklärst du dann aber besser der nächsten Wand statt hier.

Geht der Pöbel schon wieder los?

nein, ich möchte nur nicht, dass hier im Forum Unsinn, den ich erkennen kann, unkommentiert stehen bleibt. Ich befürchte dass negative Bewertungen von Anfängern nicht ausreichend gewürdigt werden.

Meine Antwort ist tie(%user); und das Binden einer Variablen an eine Klasse ist sehr wohl OOP, aber hallo!

Davon stand nichts in dem Posting oder Threadzweig auf den ich geantwortet habe und die Objektorientierung hat nichts mit tie zu tun sondern steckt in der Klasse selbst.

mfg
Woodfighter

[Felix Riesterer]

Lieber pl,

Geht der Pöbel schon wieder los?

anscheinend machst Du irgendetwas falsch.

Meine Antwort ist tie(%user);

Und das ist tatsächlich PHP-Code? Die Frage hatte als Tags unter anderem "PHP", und Du antwortest mit Perl-Code - obwohl auch Deine Antwort mit "PHP" getagged ist! Anscheinend machst Du irgendetwas falsch.

und das Binden einer Variablen an eine Klasse ist sehr wohl OOP, aber hallo!

Dein Nickname lautet inzwischen "pl", was sicherlich auch für die von Dir favorisierte Programmiersprache Perl steht. Dass Du diese Sprache und Dein in Perl geschriebenes Framework immer wieder in Threads anbringst, die sich so überhaupt nicht mit Perl und seiner Umsetzung von OOP vereinbaren lassen, ist das, was Du offensichtlich falsch machst.

Liebe Grüße,

Felix Riesterer.

[Sven Rautenberg]

Moin!

ich will über ein relativ Sicheres Login-System mit einer Datenbank kommunizieren.

Das Login integriert in einer Session Class habe ich fertig.

Absicht: Ich will noch passwort, user unnd userlevel in eine Datenbank reinschreiben, prüfen und auslesen, hashen uw.. Außedem möchte ich fest definirte tabellen Classes erstellen.

Frage: was spricht dagegen wenn ich das alles seperiert in Klassen schreibe?

Z.B.:

class password extends session { ... }

oder z.B.:

class table extends PDO { ... }

Was spricht dafür?

Ich hab die anderen Antworten noch nicht gelesen, aber dein Ansatz gefällt mir nicht.

Vernünftig wäre:

class password {
  public function __construct(session $session) {}
}

und

class table {
  public function __construct(PDO $pdo) {}
}

Vererbung ist in OOP leider genau das Beispiel, mit dem man die Einsteiger in Tutorials bombardiert, es führt aber zu schlechtem Code.

Grüße Sven

[woodfighter]

Tach,

Ich hab die anderen Antworten noch nicht gelesen,

*schonmalwegschleich*

mfg
Woodfighter

[Sven Rautenberg]

Moin!

Vererbung ist in OOP leider genau das Beispiel, mit dem man die Einsteiger in Tutorials bombardiert, es führt aber zu schlechtem Code.

Um das mal auszuführen: In Tutorials werden gerne "Autos" als Beispiel herangezogen.

class Fahrzeug {}

class Auto extends Fahrzeug {}
class Sportwagen extends Auto {}

class LKW extends Fahrzeug {}

Es wird dann im weitern Verlauf darüber philosophiert, dass Fahrzeuge als Eigenschaft beispielsweise die Anzahl von Rädern haben (weswegen man als Fahrzeug auch Motorräder machen könnte), oder die Anzahl von Sitzplätzen. LKW haben vielleicht noch einen Ladungstyp und maximale Zuladung, und Sportwagen eine Höchstgeschwindigkeit.

Dabei ist immer im Hinterkopf zu behalten: Auch wenn objektorientierte Beispiele Real-Welt-Objekte verwenden, geht es ja nie darum, diese nachzubilden - es geht höchstens darum, deren elektronisches Abbild so zu bauen, wie die zu lösende Aufgabe es vorsieht.

Angenommen also, man möchte Transportprobleme lösen, so würde die Anzahl der Räder irrelevant sein, die Anzahl der Sitzplätze und/oder die Zuladung aber sehr wohl interessieren.

Reduzieren wir das Beispiel mal auf "Verreisen von Personen":

class Fahrzeug {
  protected $sitzplaetze = 1; // es gibt immer einen Fahrer
  protected $fahrgaeste = [];
}

class Auto extends Fahrzeug {
  protected $sitzplaetze = 4;
}
class Sportwagen extends Auto {
  protected $sitzplaetze = 2;
}

Die Frage der Ladekapazität wäre damit erschlagen. Man kann sich jetzt an der Klasse "Fahrzeug" Methoden ausdenken, die das Ein- und Aussteigen von Fahrgästen regelt und dafür sorgt, dass nur maximal die erlaubte Anzahl an Personen drin sitzt etc.

Eine wichtige Aufgabe beim Lösen von Transportproblemen ist aber, dass man VON A NACH B will. Deswegen gibt es:

class Fahrzeug {
  protected $sitzplaetze = 1; // es gibt immer einen Fahrer
  protected $fahrgaeste = [];

  public function fahreNach($zielbeschreibung) {}
}

Wenn man irgendwo hin fahren will, braucht man Navigationshilfen. Für dieses Beispiel soll als Realwelt-Abbild gelten: Das Fahrzeug braucht ein Navi.

So ein Navi ist komplizierter elektronischer Krams, der mit irgendwelchen Datenbanken und GPS-Satelliten eine Route ermittelt. Trotzdem würde man jetzt nicht sowas machen: class Fahrzeug extends Navi {} - was hat denn das Fahrzeug mit dem Navi gemeinsam? Man würde das Navi aber ins Fahrzeug tun, damit es im Fahrzeug benutzt wird.

class Fahrzeug {
  protected $sitzplaetze = 1; // es gibt immer einen Fahrer
  protected $fahrgaeste = [];
  protected $navi;

  public function __construct(Navi $navi) {
    $this->navi = $navi;
  }

  public function fahreNach($zielbeschreibung) {
    $route = $this->navi->holeFahranweisungen($zielbeschreibung);
    foreach ($route as $anweisung) {
      $this->fahre($anweisung);
    }
  }
}

Die Stärke von OOP liegt darin, dass komplexe Detaillösungen, als Objekt modelliert, nach außen ein eher simples Interface anbieten, und die inneren Vorgehensweisen - gerne mit weiteren Objekten für innere Detaillösungen - nach außen verbergen. Es interessiert die Insassen eines Fahrzeugs nicht, WIE das Navi es schafft, eine Liste von Fahranweisungen zu erzeugen. Vermutlich wird irgendwo eine Datenbank integriert sein, und ein GPS-Sensor.

Würde "Fahrzeug" von "Navi" erben, könnte man genau dieselben Sachen ebenfalls machen, es wäre dann statt $this->navi->holeFahranweisungen() einfach $this->holeFahranweisungen() zu schreiben in fahreNach().

Das Problem wäre jetzt aber, dass das Fahrzeugobjekt jetzt alle Methoden vom Navi anbietet. Außerhalb von "Fahrzeug" ginge jetzt also $fahrzeug->holeFahranweisungen() - aber wieso sollte ein FAHRZEUG jemand anderem FAHRANWEISUNGEN ausgeben können?

Deswegen ist es eine gute Vorgehensweise, mächtige Funktionalitäten in Objekten durch Zusammensetzen unterschiedlicher, aber voneinander unabhängiger Objekte zu realisieren: "Composition over Inheritance"

Wikipedia meint: "So ist es möglich, zur Laufzeit das Verhalten einer Klasse zu verändern." - was ja hier im Beispiel stimmt: Die Fähigkeiten des Navis sind nicht fest verdrahtet mit dem Fahrzeug, d.h. dem Fahrzeug kann man entweder ein einfaches Navi geben, was z.B. nur die vier Himmelsrichtungen für Anweisungen benutzt und toll für Offroad in der Wüste funktioniert, oder ein Straßennavi für Gegenden, wo Straßen existieren.

Grüße Sven