Klassenaufbau eines Gbooks

[Wasserflasche]

Hallo. Ein Gästebuch zu programmieren, ist ja schnell gemacht. Aber ich möchte mal ein Gästebuch objektorientiert programmieren. Hab mit OOP noch nicht all zu viel Erfahrung und wollte mal fragen, wie ihr den Klassenaufbau machen würdet? Ich hätte einfach ausm Bauch heraus folgendes gesagt:

Class Database:

• connect()
• sql_query()
• validate() // bzgl. des Logins

Class Guestbook:

• show_entires()
• insert_entry()
• search_entry()
• login()
  • delete_entry
  • edit_entry

 

[Gilles]

Ich würde eine allgemine mysql database klasse machen. Also connect, insert, select, update und close.
Validationen von bestimmten Sachen gehören da dann nicht rein. Das ist ja wieder etwas spezifisches. Dann eine Klasse mit dem Namen guestbook. Die würde bei mir dann noch eine zusatzklasse haben, die GuestbookDAO heisst. Das DAO kümmert sich um alle Datenbank-Zugriffe. das validieren liegt auf der Logik Seite, also in der Guestbook-Klasse.
Dann würde ich an deine rStelle onch eine user Klasse machen, da das Gästebuch und der userlogin zwei grundsätzlich verschiedene Sachen sind. Probiere bei de rPlanung immer darauf zu achten welche Komponenten du hast. Wie kannst du den Code am besten trennen. :)

 

[Wasserflasche]

Hi, danke für die schnelle Antwort.

Validationen von bestimmten Sachen gehören da dann nicht rein. Das ist ja wieder etwas spezifisches

Dachte nur, weil der Vergleich (ob die Logindaten übereinstimmen) ja auch in der DB passiert.

 

[Commodore]

Das kommt ganz darauf an, was genau dein Gaestebuch alles koennen soll. Der erste Schritt zu einem Projekt ist nicht der Klassenaufbau, sondern eine detaillierte Beschreibung von dem, was alles moeglich sein soll.

• Was fuer Felder gibt es [Name? Email? Text?]? Wie koennen diese Felder noch im nachhinein erweitert werden? Wie implementierst du die Beschraenkungen fuer die Felder [z.B. Email-Adresse muss gueltig sein]?
• Gibt es verschiedene Templates? Kann der User sich eines aussuchen?
• Captcha? Selbstgemacht/ reCaptcha? Eine weitere alternative?
• Sperren gegen viele Nachrichten der selben Person?
• Muessen Kommentare erst freigeschaltet werden?
• Sollen zu alte Kommentare automatisch geloescht werden? Blaetter-Funktion?
• Wie wird das Admin-Panel eingerichtet sein? Kann man hier auch Templates aussuchen?
• Wie sieht die Schnittstelle zwischen Datenbank und Gaestebuch aus?

Und das sind nur die Punkte, die mir ad hoc einfallen. Wenn man genauer darueber nachdenkt fallen einem sicherlich noch viel mehr Dinge ein.


Die Frage ist auch, ob du wirklich OOP nutzen willst. OOP bietet einige Vorteile:

• Du kannst von einer Klasse mehrere Instanzen erzeugen, die dann unabhaengig voneinander funktionieren. Beispielsweise ist bei einem Spiel jedes Monster eine Instanz der Klasse "Monster". Dabei kann man jedem Monster eigene Attribute [Angriff, Verteidigung etc.] geben, allerdings trotzdem gemeinsame Methoden der Hauptklasse [Kampf mit dem Monster, Anzeige auf dem Bildschirm etc.] nutzen.
• Vererbung ist auch ein grosser Vorteil von OOP. Nimmt man wieder das Beispiel des Spiels, so kann es eine Oberklasse "Sprite" geben, die die wichtigsten Anzeigefunktionen beinhaltet. Davon vererbt man nun die Klassen "Monster" und "Held", die zwar in ihrer Implementierung unterschiedlich sind, jedoch beide die Anzeige-Methoden der Oberklasse nutzen koennen.
• Du kannst eine Klasse erstellen, die diverse Anwendungsmoeglichkeiten in verschiedenen Projekten hat. Dabei bleibt der Aufbau der Methoden und Attribute gleich, jedoch haben die Attribute je nach Projekt unterschiedliche Werte. Damit musst du dann die Klasse nur einmal erstellen, kannst sie allerdings in vielen verschiedenen Projekte einbinden. Ein Beispiel fuer soetwas ist so ziemlich jede Template-Engine. Sie wird nur einmal geschrieben, kann dann allerdings fuer viele Projekte die Darstellung uebernehmen.

Deine bisherige Idee beinhaltet nichtmal Attribute, damit koenntest du genausogut auch eine Sammlung von Funktionen in eine eigene Datei schreiben und diese dann genauso nutzen.

 

[crash]

Die Klasse Guestbook würde ich als Model anlegen, welches nichts anderes macht als ein Interface für die Datenbanktabelle zu sein und die Daten bereit hält.

Ein Script (oder besser Controller) bedient sich dann einfaches dieses Models.

Als Beispiel kann man hier den ZFs Quickstart anbringen.

 

[CGollhardt]

Dann eine Klasse mit dem Namen guestbook. Die würde bei mir dann noch eine zusatzklasse haben, die GuestbookDAO heisst. Das DAO kümmert sich um alle Datenbank-Zugriffe.

Sorry, wenn ich jetzt mal kurz den Thread "zweckentfremde", aber wie würdest du das tun?
Google spuckt mir immer nur folgendes aus:

class a {
   var downclass;
   function a {
      var downclass = new b();
   }
}
class b {
   //...
}

Gibt es da auch eine andere Möglichkeit wie zb. in vb.net, die ungefähr so aussieht?

class a {
   class b {
      var $Test = 'test';
   }
}
echo $a.$b -> Test;
echo $a -> $b -> Test;

Oder wird sowas wie im ersten Beispiel gehandhabt?

 

[Gilles]

Sorry, wenn ich jetzt mal kurz den Thread "zweckentfremde", aber wie würdest du das tun?
Google spuckt mir immer nur folgendes aus:

Ich würde das wie in deinem ersten Beispiel regeln. Fall 2 sollte nicht möglich sein. Wenn ja, ist es jedenfall ein sehr unschöner Stil :)
Ich mache 2 seperate klassen und benutze die DAO Klasse in der eigentlichen Klasse.

 

[crash]

namespace a {
    class b
    {
        public static $test = 'test';
    }
}

namespace {
    class a
    {
    }

    var_dump(a/b::$test);
    var_dump(new a/b);
    var_dump(new a);
}

Wäre das akzeptabel?

/ ist ein Backslash, aber das Forum frisst die.

 

[CGollhardt]

Ich würde das wie in deinem ersten Beispiel regeln. Fall 2 sollte nicht möglich sein. Wenn ja, ist es jedenfall ein sehr unschöner Stil :)

Das ein extra Objekt übersichtlicher und schöner ist, finde ich auch. Im Fallbeispiel Gästebuch finde ich es auch gut so class db und class guestbook zu trennen, aber wenn man die Klasse guestbook aufteilt finde ich es schöner, wenn
zb. class guestbook_view, class guestbook_model und class guestbook_controller
innerhalb der class guestbook sind. Weiß nicht, finde ich persönlich schöner. Kann ja bei zu langen code auch mit include/require arbeiten.

Aber dein Nachposter hat mich jetzt wirklich auf was gebracht.

Wäre das akzeptabel?

Das sieht doch aufjedenfall sehr nett aus, wusste garnicht dass es sowas wie namespace gibt. Muss ich gleich mal ausprobieren.

Da kann ich ja Fallbezogen einen Namespace guestbook machen, und darin zb die mvc klassen.

 

[crash]

Wenn ich das richtig sehe müssen Sub-Klassen in VB.net auch vorher deklariert werden. Ich sehe also keinen Unterschied zu PHP. Somit hingt dein oberes Beispiel.

 

[CGollhardt]

Wenn ich das richtig sehe müssen Sub-Klassen in VB.net auch vorher deklariert werden. Ich sehe also keinen Unterschied zu PHP. Somit hingt dein oberes Beispiel.

Also ich weiß nicht wie es sich mit dem public gültigkeitsbereich verhält, aber im private bereich spreche ich es einfach über den Klassennamen an. Also sprich

me.subclass.method()

Obwohl option strict = true.

 

[crash]

Ja und darin liegt der Unterschied. Du greifst nur auf statische Eigenschaften zu. Vorher wolltest du allerdings b als Instanz erzeugen.

 

[CGollhardt]

Ja und darin liegt der Unterschied. Du greifst nur auf statische Eigenschaften zu. Vorher wolltest du allerdings b als Instanz erzeugen.

Ja das stimmt, so wollte ich es allerdings nicht verwenden, dachte nur ich kanns damit veranschaulichen. PHP kennt ja nicht die unterschiede zwischen Public und Private (Stand PHP 4, muss mich eindeutig mit PHP 5 auseinandersetzen, vielleicht gibt es sowas dort?)
Aber für meine Zwecke denke ich mal, ist der von dir vorgeschlagene Namespace gefundes "Fressen".

 

[crash]

public, protected und private: PHP: Visibility - Manual
Was dauert das eigentlich so lange? Kein Mensch schreibt mehr PHP4.

 

[CGollhardt]

Was dauert das eigentlich so lange? Kein Mensch schreibt mehr PHP4.

Einer aufjedenfall mindestens :mrgreen:

Naja bedingt durch meine Ausbildung kam ich immer nur zum vb.net Programmieren. Und naja irgendwie hatte ich privat eine Zeit lang keine PHP Projekte mehr gestartet, da ich es ziemlich interessant fand Windows Form Anwendungen zu schreiben.

Aber ich konnte mein PHP Fable nicht so ganz im Stich lassen :cry: ()

Naja seit 3 Wochen wieder dabei, ich merk schon Ihr macht Druck

 

[Wasserflasche]

CGollhardt, was ist eigentlich so schwer daran, ein eigenen Thread aufzumachen?

 

[CGollhardt]

CGollhardt, was ist eigentlich so schwer daran, ein eigenen Thread aufzumachen?

Liebend gerne, aber wie stellst du dir das vor? Crash, komm doch bitte in meinen Thread? Ne jetzt mal ernsthaft tut mir ja leid, dass ich so dazwischen gefunkt habe, aber ich lesen Threads um was dazuzulernen. Wenn ich helfen kann helfe ich, wenn ich was lernen kann, lerne ich, und wenn ein User etwas vorschlägt denke ich, er weiß es auch, wie er es programmieren würde.

 

[struppi]

Ich glaube Wasserflasche hätte gerne hier in dem Thread über seine Frage diskutiert. Gegen das Lesen hat ja keiner was gesagt, aber das Schreiben hättest du lieber woanders gemacht. So sitzt der OP mit seiner halbbeantworteten Frage da. Das ist reichlich unhöflich

 

[Asterixus]

OOP ist nicht in jedem Anwendungsfall geeignet. Ein Gästebuch ist, wenn es ein einfaches sein soll, prozedural weitaus klarer als ein objektorientiertes.
Wenn es aber Möglichkeiten wie BB-Codes, HTML-Codes, Eintragsänderung, Eintragsköschung, Eintragsfreischaltung, Zugangsverboten, komplexe rechtespezifische ACPs und Eintragsreporting geben sollte, dann kommt es in Frage.

Wichtig ist, dass du einen Plan von dem machen musst, was dein Gästebuch enthält.
Danach stellst du die Datenbankstruktur auf.
Auf diese Struktur baust du dann die Klassen auf.

Wild drauf los programmieren war noch nie die richtige Lösung.

Außerdem solltest du bedenken, welches Encoding du benutzt. Ob mehrere verschiedene Datenbanken benutzt werden könnten. Ob man sogar eventuell ohne Datenbank auskommen könnte (Textdateien), usw.