OOP Problem - Wie lösen

[kaptainIglo]

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:

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?

[ChrisvA]

Es gibt reichlich fertige mailer-Klassen. Nutze am Besten eine von denen.

[Ma27]

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)

class AnyInteractor
{
    private $sender;
    private $dao;

    public function __construct(MailerInterface $mailer, DAOInterface $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:

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

[kaptainIglo]

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

[Ma27]

@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

[litterauspirna]

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.