Noch zum Thema OOP

[Matti Mäkitalo]

Hi,

Ok, aber nehmen wir mal an ich will ein Internes Message System machen (um jetzt doch ein Beispiel zu nennen) wie man es so oft bei diversen Foren sieht. Hier könnte ich 10 "unds" in die Beschreibung der Klasse packen.

Eine Nachricht ist eine Nachricht. D.h., sie hat einen Absender, einen Empfänger, vielleicht einen Betreff, einen Text. Sendezeit, Lesezeit, Löschzeitpunkt. Für die Beschreibung ausreichend ist, dass es eine private Nachricht zwischen zwei Nutzern des Systems ist.

Wäre es hier z.B. sinnvoll eine Klasse für alle Aktionen zu einer Nachricht (Speichern, als gelesen markieren, löschen, usw.) und eine Klasse für alle Aktionen für die gesamten Nachrichten (Posteingang, Postausgang, usw.). Oder doch alles in einer Klasse?

Erster Denkfehler: warum weiß die Nachricht, welche Aktionen auf ihr möglich sind? Eine Nachricht zu speichern gehört m.E. nicht zu den Dingen, die eine Nachricht können sollte.

Etwas anderes ist es, die Nachricht als gelesen zu markieren. Dies hat meiner Erfahrung nach zwei Teile. (1) Setzen des Zustands in der Nachricht (d.h. Lesezeitpunkt setzen). Dazu würde ich eine Methode in der Nachrichtenklasse schreiben, welche den Lesezeitpunkt setzt. (2) Speichern/Persistieren des neuen Zustands. Gehört m.E. nicht zu den Dingen, die die Nachricht wissen sollte.

Ich nutze derzeit Doctrine als ORM. Teil 1 findet tatsächlich in meiner Entity statt (die aber so geschrieben ist, dass sie, zumindest was den PHP-Teil angeht, nichts von Doctrine weiß). Für Teil 2 schreibe ich einen Transaktionslayer, welcher zwichen Frontend-Code und Business-Code steht. Der Transaktionslayer ist eigentlich nichts weiteres als eine high-level API auf die Business-Use-Cases und tut i.d.R. nichts anderes, als die entsprechende Business-Methode(n) aufzurufen und dann die DB-Transaktion zu beenden (den Entity-Manager zu flushen). Wenn ich es nicht ganz falsch verstanden habe, dann ist es etwa das Pattern, was allgemein als "Boundary" bekannt ist.

Bis die Tage,
Matti