Ankündigung

Einklappen
Keine Ankündigung bisher.

OOP Problem - Wie lösen

Einklappen

Neue Werbung 2019

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

  • OOP Problem - Wie lösen

    Hi,

    folgende Aufgabe:
    Ich habe ein Formular, das per Post übertragen wird.
    Nun sollen die Daten in eine DB eingetragen und danach per E-Mail verschickt werden. Es könnte so aussehen:

    PHP-Code:
    public function sendFormular($data) {
     
    Eintrag in die DB
     Wenn erfolgreich
      versende E
    -Mail

    Wenn der Eintrag in die DB erfolgreich war, liefert die DB die ID des Eintrags zurück. Diese ID wird dann in der E-Mail verlinkt.
    Der Ablauf in einer Funktion ist an sich kein Problem.
    Ich möchte nun den E-Mailversand in eine eigene Klasse stecken.
    Frage mich nur, wie ich das sauber lösen kann. Die ID, die die DB liefert sollte ja auch an den E-Mailversand mitgegeben werden.
    Wie kann in OOP darstellen?


  • #2
    Es gibt reichlich fertige mailer-Klassen. Nutze am Besten eine von denen.
    mysql ist veraltet Mails senden: Ohne Probleme und ohne mail()
    PHP-Code:
    echo 'PS: <b>Meine Antwort ist keine Lösung, sondern nur eine Hilfe zur Lösung.</b>'

    Kommentar


    • #3
      http://swiftmailer.org/

      Frage mich nur, wie ich das sauber lösen kann. Die ID, die die DB liefert sollte ja auch an den E-Mailversand mitgegeben werden.
      Wie kann in OOP darstellen?
      Ich würde im Constructor einfach ne Mailer Instanz injizieren.

      Für eine Implementierung könntest du eine Art Interactor implementieren, der die gesamte Business Logik ausführt (http://www.whitewashing.de/2012/08/1...nteractor.html)
      PHP-Code:
      class AnyInteractor
      {
          private 
      $sender;
          private 
      $dao;

          public function 
      __construct(MailerInterface $mailerDAOInterface $dao)
          {
              
      // set properties
          
      }

          public function 
      process(Request $request)
          {
              
      // execute database queries

              
      $id $result->getId();

             
      // send message with swift mailer
          
      }

      Nun kannst du für das DAO (Data Access Object) und den Mailer Schnittstellen schreiben und implementieren:

      PHP-Code:
      interface DAOInterface
      {
          public function 
      loadDatasetById($id);
      }

      interface 
      MailerInterface
      {
          public function 
      sendMail();

      Wie du sehen kannst, abstrahiert das DAOInterface die Datenbank zugriffe. Das Mailer Interface kann jetzt eine mit einer Mailing Klasse (oben ist eine verlinkt) die Emails senden. Der Vorteil an diesem Ansatz ist die Austauschbarkeit der Mailing Klasse und des DAOs.

      Das Request Objekt entspricht in deinem Beispiel $data, nur als Domain Model implementiert

      Ich hoffe, das hilft ein klein wenig weiter,
      LG Ma27
      https://github.com/Ma27
      Javascript Logic is funny:
      [] + [] => "", [] + {} => object, {} + [] => 0, {} + {} => NaN

      Kommentar


      • #4
        Danke für den Tipp. So was in die Richtung habe mir vorgestellt. Ich verstehe es nur noch nicht ganz.
        Kannst Du mir die Vorgehensweise mit den Interfaces näher erklären?

        Gruß
        HP

        Kommentar


        • #5
          @kaptainIglo,

          vorweg, so würde ich aktuell vorgehen.

          also Interfaces enthalten Methodendeklarationen - die Methoden haben jedoch keinen Inhalt. Wenn jetzt eine Klasse ein Interface implementiert, MUSS sie diese Methoden enthalten. Dadurch wird das schön gekapselt, da Klassen, die eine Klasse implementieren, nur prüfen müssen, ob das Interface implementiert wird und müssen sich nicht mehr um die Implementierung kümmern. Wenn du jetzt Beispielsweise ein Dateisystem statt der Datenbank nutzen willst, musst du die Klasse einfach nur austauschen, im Konstruktor die andere Klasse angeben, diese muss dann das Interface implementieren und dann die Daten aus einem Dateisystem laden. Dadurch kannste beim testen auch ein Mock DAO, also ein DAO, das nur zum testen entwickelt wurde (wobei sich da Mocking Frameworks eher eignen) und dieses dann in Verhaltenstests oder Unit Tests nutzen.
          Ich würde das auf diese Weise wegen der Kopplung nutzen und gleichzeitig musst du für den Mailler nur einen Adapter schreiben, falls du von Swift mal auf PHPMailer umsteigen solltest und du kannst beim testen das Mailing einfach weglassen, indem du ein Klasse schreibst, die das Interface implementiert aber keine Emails versendet.

          Ich hoffe, dass das jz ein wenig klarer geworden ist,

          LG
          https://github.com/Ma27
          Javascript Logic is funny:
          [] + [] => "", [] + {} => object, {} + [] => 0, {} + {} => NaN

          Kommentar


          • #6
            Zitat von kaptainIglo Beitrag anzeigen
            Danke für den Tipp. So was in die Richtung habe mir vorgestellt. Ich verstehe es nur noch nicht ganz.
            Kannst Du mir die Vorgehensweise mit den Interfaces näher erklären?

            Gruß
            HP
            Guten Morgen,

            also Interfaces haben an sich nichts mit Kapselungen zu tun. Sie bilden Schnittstellen und da hast am Ende z.B. anahnd eines Strategy Patterns sehr einfach Klassen austauschen.
            Ein Interface gibt vor welche Methoden eine Klasse, die dieses Interface implementiert enthalten muss.
            Somit sicherst du die Grundfunktionalität der Objekte.

            Wie in dem Beispiel von Ma27 zu sehen ist, gibt es einen Typehint gegen ein Interface. Demzufolge ist es egal welches Objekt du da übergibst, hauptsache es implementiert das Interface.
            Aus dem Dynamo Lande kommen wir. Trinken immer reichlich kühles Bier. Und dann sind wir alle voll, die Stimmung ist so toll. Aus dem Dynamo Lande kommen wir.
            http://www.lit-web.de

            Kommentar

            Lädt...
            X