Ankündigung

Einklappen
Keine Ankündigung bisher.

Subject-Observer nicht 1:n sondern n:1

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Subject-Observer nicht 1:n sondern n:1

    Hallo zusammen,
    ich stehe vor folgender Problemstellung:
    Ich möchte eine Art Dashboard realisieren, das den Benutzer auf der Startseite nach dem Login über die neuesten Ereignisse unterrichtet. Solche Ereignisse können neue private Nachrichten sein, neu zugeteilte Aufgaben und/oder Zuständigkeiten, neu angelegte Projekte im eigenen Zuständigkeitsbereich etc.
    Für die Realisierung habe ich an das Subject-Observer-Pattern gedacht, allerdings in etwas "entfremdeter" Form. Ich habe nicht ein Subject mit n Observern, sondern n subjects mit einem Observer. Damit verlagert sich natürlich die Aufgabe der Informationsfilterung/-aufbereitung zum Subject. Jedes Subject muss sich also selber darum kümmern die relevanten Informationen in eine Form zu bringen, die der Observer versteht.
    In meinem Beispiel hatte ich daran gedacht im Subject vor jedem notify() einen Array mit den vom Dashboard benötigten Informationen bereitzustellen, der dann vom Dashboard beim update() abgerufen und verarbeitet wird.
    Was mir daran noch nicht so gefällt ist eben genau dieser Punkt, dass sich ein großer Teil des Systems zu einem gewissen Grad um das Dashboard herum aufbauen muss. Mir fällt aber auch zur Zeit keine elegantere Lösung ein.
    Vielleicht hat hier jemand eine Anregung?


  • #2
    Standardisierte Ausgabe/Auslese-Schnittstelle definieren, diese im Dashboard abprüfen, alle Elemente dort anmelden und Dashboard „ruft zurück“.
    --

    „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
    Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


    --

    Kommentar


    • #3
      Zitat von nikosch Beitrag anzeigen
      Standardisierte Ausgabe/Auslese-Schnittstelle definieren, diese im Dashboard abprüfen, alle Elemente dort anmelden und Dashboard „ruft zurück“.
      Schnell, kurz und prägnant
      Ich kann mir grad noch nicht wirklich vorstellen wie das genau aussehen soll, aber die ersten Ideen nehmen schon Form an, ich lass mir das mal durch den Kopf gehen und melde mich dann gegebenenfalls nochmal mit konkreterem Beispiel und Frage. Danke erstmal für den Denkanstoß

      Kommentar


      • #4
        Ich kann mir grad noch nicht wirklich vorstellen wie das genau aussehen soll,
        Ich noch weniger Kommt letztlich drauf an, was das so für Elemente sind.
        --

        „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
        Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


        --

        Kommentar


        • #5
          Ich habe mich gerade mal hingesetzt und ein wenig überlegt.
          Momentan habe ich so ein Konzept im Kopf:
          PHP-Code:
          <?php
          interface Reporter {
              public function 
          report();
          }
          interface 
          Listener {
              public static function 
          attachReporter(Reporter $reporter);
              public static function 
          detachReporter(Reporter $reporter);
              public static function 
          callReporters();
          }
          class 
          PrivateMessage implements Reporter {
              private 
          $forwarder;
              private 
          $recipient;
              public function 
          send($forwarder,$recipient,$message) {
                  
          // Nachricht versenden
                  
          $this->forwarder $forwarder;
                  
          $this->recipient $recipient;
                  
          Dashboard::attachReporter($this);
              }
              public function 
          report() {
                  return 
          "Neue Nachricht von {$this->forwarder} an {$this->recipient}";
              }
          }
          abstract class 
          Dashboard implements Listener {
              private static 
          $reporters = array();
              public static function 
          attachReporter(Reporter $reporter) {
                  
          self::$reporters[] = $reporter;
              }
              public static function 
          detachReporter(Reporter $reporter) {
                  
          self::$reporters array_diff(self::$reporters,array($reporter));
              }
              public static function 
          callReporters() {
                  foreach(
          self::$reporters as $reporter) {
                      echo 
          $reporter->report();
                      
          // Report verarbeiten
                  
          }
              }
          }
          $PM = new PrivateMessage;
          $PM->send("Hans","Karl","Hi Karl!");
          Dashboard::callReporters();
          ?>
          Sieht jemand spontan Schwächen bei dem Konzept?
          Ich bin grad noch am überlegen ob es nicht sinnvoller wäre, das Interface Listener wegzulassen und stattdessen eine abstrakte Klasse zu bauen, an den sich beim Programmstart verschiedene Listener anmelden können und im Programmablauf dann die Reporter (mit konkreter Angabe für welche Listener?).
          Andererseits sehen ja wiederum die Informationen die von den Reportern beim Aufruf von report() zurückgegeben werden immer gleich aus, brauche ich dann überhaupt verschiedene Listener für ein und dieselbe Information? Wobei ich gerade sowieso kein anderes Beispiel für einen Listener als das Dashboard parat hätte. Aber das heißt ja nichts. ^^

          Kommentar


          • #6
            Vielleicht könnte das Mediator-Pattern für dich interessant sein.
            Refining Linux: “Performing Push Backups – Part 1: rdiff-backup

            Kommentar


            • #7
              Das sieht interessant aus, lasse ich mir mal durch den Kopf gehen. Vielen Dank für den Hinweis.

              Kommentar


              • #8
                Zitat von SinnlosS Beitrag anzeigen
                (...) die neuesten Ereignisse unterrichtet. Solche Ereignisse (...)
                Ich würde das groß geschriebene Wort ins Englische übersetzen.

                Event-Dispatcher

                Edit: Hatte einen falschen Link gesetzt. Es gibt jedoch ein empfehlenswertes Buch, welches ein gleichnamiges Pattern beschreibt.

                Kommentar


                • #9
                  Für solche Infos eignet sich PoEAA von Martin Fowler als Nachtlektüre.
                  Aber bitte die englische Ausgabe - ist bei Computer-Fachbüchern meist sehr angeraten.
                  actra.development - Zend Certified Engineer for PHP5 - actra-oss @ github

                  Kommentar


                  • #10
                    Danke auch an Renner und G.Schuster.
                    PoEAA habe ich mir gerade mal beim Händler meines Vertrauens bestellt. Hab demnächst mal wieder etwas Luft für neue Lektüre.
                    Am WE werde ich mich wieder meiner Problemstellung hier widmen und mir dazu dann auch nochmal das Event-Dispatcher-Pattern zu Gemüte führen.

                    Kommentar

                    Lädt...
                    X