Patrick: OO Interaktion von Objekten?

Guten "Morgen",

ich bin objektorientiertem Programmieren nicht ganz fremd - aber es war alles Learning By Doing - eine Zeitlang mal etwas Java. Derzeit bin ich damit beschäftigt, ein PHP-Webprojekt auf OO umzustellen. Der berüchtigte Spaghetti-Code wurde mir auf Dauer zu unübersichtlich und ich möchte die Einbindung weiterer Personen in Teilbereiche des Projektes einbeziehen. Soviel zum Hintergrund.

Ich bin also mit den fundamentalen Begriffen von OO vertraut, sie werden ja auch in jedem Tutorial von Beginn bis zum Ende durchgekaut. Allerdings beschäftigen die sich meistens mit einzelnen Objekten. Die Frage, wie man die Interaktion von Objekten sinnvoll programmiert, konnte ich bisher nicht beantworten.

Das heisst, ich habe nun sagen wir ein Objekt, das die HTML Seitenelemente ausgibt, Header, Footer etc...  Ein Objekt, das den Seiten-"Inhalt" per Interaktion mit Formulardaten und Datenbank aufbereitet und an das erstgenannte Objekt übergibt. Weiterhin ein Objekt zur Durchführung von Datenbank-Abfragen, eines zur Bereitstellung der Text-Strings in der jeweils gewählten Sprache.. Und und und.

Im Moment erstelle ich in der Hauptseite des Scripts (sagen wir index.php) jeweils eine Instanz jedes Objektes und gebe diese Objekte als Parameter an die __construct Methode weiter (damit zum Beispiel ein Objekt der Klasse "Inhalt" mit dem Datenbank Objekt interagieren kann). Ich bin mir aber nicht sicher, ob diese Vorgehensweise sinnvoll und guter Programmierstil ist? Insbesondere ist es mühsam, wenn ein Objekt (vielmehr, eine Klasse) später Zugriff zu einem weiteren Objekt bekommen soll, muss ich das bei jeder Instantiierung im gesamten Projekt manuell anpassen (sprich, die Paramter bei der Verwendung von new ...() um ein neues Objekt ergänzen.)

Eine Alternative wäre, die benötigten Objekte in den Klassen per 'global' sichtbar zu machen. Aber auch das erscheint mit irgendwie suspekt...

Hoffe, mit soviel Texte meine Frage/Verwirrung deutlich gemacht zu haben - vielleicht habt ihr ja einen Denkanstoss für mich.

Noch etwas: In dem oben beschriebenen Setup nutze ich von jeder Klasse nur eine Instanz. Warum also überhaupt instantiieren und nicht gleich alle Methoden static aufrufen? Ich weiss, dass "man das nicht macht". Warum nicht?

Gruss,
Patrick

  1. Das heisst, ich habe nun sagen wir ein Objekt, das die HTML Seitenelemente ausgibt, Header, Footer etc...  Ein Objekt, das den Seiten-"Inhalt" per Interaktion mit Formulardaten und Datenbank aufbereitet und an das erstgenannte Objekt übergibt. Weiterhin ein Objekt zur Durchführung von Datenbank-Abfragen, eines zur Bereitstellung der Text-Strings in der jeweils gewählten Sprache.. Und und und.

    Du kannst schon am Namen der Objekte erkennen, ob diese sinnvoll sind. Welche Namen hast Du den Dingern gegeben?

    Eine Alternative wäre, die benötigten Objekte in den Klassen per 'global' sichtbar zu machen. Aber auch das erscheint mit irgendwie suspekt...

    Das liest sich nicht gut.

    Noch etwas: In dem oben beschriebenen Setup nutze ich von jeder Klasse nur eine Instanz. Warum also überhaupt instantiieren und nicht gleich alle Methoden static aufrufen? Ich weiss, dass "man das nicht macht". Warum nicht?

    Von jeder Klasse nur eine Instanz? Welche Klassen hast Du denn so?

    1. Hi.

      Du kannst schon am Namen der Objekte erkennen, ob diese sinnvoll sind. Welche Namen hast Du den Dingern gegeben?

      eine typische Seite sieht momentan so aus (zusammengefasst):

      ===============================================
      <?php require_once 'config.php'; // Doctype,__autoload,session_start

      $menu = array(
      "summary" => array("summary"),
      "account" => array("account","data","skills","settings"),
      "jobs" => array("current","open","bidding","ratings"),
      "..." => array("..."),
      "..." => array("..."));  // Struktur für ein 2-Level Menü

      $db = new Database();
      $language = new Language($db);

      /* Die Variablen $item und $tab werden an dieser Stelle initialisiert
      und teilen der Instanz von menuPage mit, welche Seite aus dem Menü - siehe oben - selektiert ist. */

      $page = new menuPage($language,$db,$menu,$item,$tab);

      $content = new $page->currentTabName($language,$db);

      $content->secure = true;  // Nur für angemeldete Nutzer sichtbar

      $page->build($content);  // Die Methode build gibt Header und das
                               // Menü aus, fügt den durch $content
                               // generierten Seiteninhalt ein und gibt
                               // einen Footer aus.
      ?>

      Eine Alternative wäre, die benötigten Objekte in den Klassen per 'global' sichtbar zu machen. Aber auch das erscheint mit irgendwie suspekt...

      Das liest sich nicht gut.

      Das war meine Vermutung! Obwohl es funktioniert...

      Von jeder Klasse nur eine Instanz? Welche Klassen hast Du denn so?

      Siehe oben. Wieso sollte ich mehrere Instanzen benötgen? Das Skript gibt EINE Seite aus, braucht EINE Datenbankschnittstelle, die Seite hat ein Interface in EINER gewählten Sprache.

      Wo liegen meine fundamentalen Design-Fehler ;-) ?

    2. Bin mittlerweile auf das Design-Pattern "Singleton" gestoßen.

      In meinem Projekt (Auszug/Aufbau siehe vorheriges Posting) würde ich bei Anwendung dieses Patterns fast ausschließlich Singleton-Objekte verwenden.

      Ist das schlechter OO-Stil? Wenn ja, warum?

      Wie sieht bei euch das typische Grundgerüst eines objekt-orientierten Web-Projektes aus?

      Mir fehlt wohl noch ein wenig das OO-'Mindset' aber ich finde auch bisher keine geeigneten Quellen -die meisten Quellen zum Thema erläutern einfach in Isolation die verschiedenen OO-Techniken.

      Zuletzt läuft es wieder auf die Frage hinaus, ob OO in PHP-Webprojekten überhaupt sinnvoll ist, oder?

      Gruss,
      Patrick

  2. Das heisst, ich habe nun sagen wir ein Objekt, das die HTML Seitenelemente ausgibt, Header, Footer etc...  Ein Objekt, das den Seiten-"Inhalt" per Interaktion mit Formulardaten und Datenbank aufbereitet und an das erstgenannte Objekt übergibt. Weiterhin ein Objekt zur Durchführung von Datenbank-Abfragen, eines zur Bereitstellung der Text-Strings in der jeweils gewählten Sprache.. Und und und.

    Ich glaube du bist gerade dabei zu entdecken, das das MVC Konzept sinnvoll ist. Zusätzlich zu MVC sind noch die Entwurfsmuster der GoF hilfreich. Die Phase der Erkennung der Notwendigkeit habe ich gerade hinter mir, muss aber sagen dass ich grosse Schwierigkeiten habe dieses in die Praxis umzusetzen. Da alle Objekte nur noch lose oder gar nicht miteinander verbunden sind und lediglich die sich aus den Entwurfsmustern ableitenden Klassen für die Kommunikation untereinander zuständig sind.

    Ideen wie das ganze funktioniert findest du, wenn du dir die Dokus einiger Frameworks anschaust, z.b. Struts

    Struppi.

    --
    Javascript ist toll (Perl auch!)
    1. Ideen wie das ganze funktioniert findest du, wenn du dir die Dokus einiger Frameworks anschaust, z.b. Struts

      Struppi.

      Danke für die Hinweise.

      Ich bin auch gerade dabei, Design Patterns zu entdecken und werde versuchen, das ein oder andere zu übernehmen. Ein Singleton-Objekt gefällt mir schon wesentlich besser, als zig-mal Objektreferenzen hard-coded als Parameter zur Instantiierung von neuen Klassen zu übergeben.

      1. Ich bin auch gerade dabei, Design Patterns zu entdecken und werde versuchen, das ein oder andere zu übernehmen. Ein Singleton-Objekt gefällt mir schon wesentlich besser, als zig-mal Objektreferenzen hard-coded als Parameter zur Instantiierung von neuen Klassen zu übergeben.

        Kann jemand mal hier sauber ein "Singleton" definieren?