Block 4 hat ausschließlich Observer gezeigt - AwardPointsOnOrderPlaced (Kapitel 30), ReversePointsOnCreditmemoSave (Kapitel 31), das eigene mironsoft_loyalty_customer_tier_changed-Event (Kapitel 35). Block 5 beginnt in Kapitel 38 mit Plugins - und Kapitel 39 zeigt bereits im ersten Plugin-Beispiel, dass es dort etwas gibt, das kein Observer je könnte: den Rückgabewert einer Methode tatsächlich ändern. Dieses Kapitel macht den Unterschied explizit, bevor Block 5 in die Technik einsteigt.

Die eine strukturelle Grenze

Ein Observer bekommt Objekte per Referenz übergeben und kann sie durchaus verändern - Kapitel 30 setzt $order->setData('loyalty_points_earned', ...) genau deshalb erfolgreich. Was ein Observer nicht kann: den return-Wert der Methode beeinflussen, die das Event dispatcht hat, oder ihre Argumente vor deren Ausführung abfangen und ersetzen. sales_order_place_after feuert, nachdem die Bestellung schon platziert ist - der Observer kommentiert das Ergebnis, er entscheidet nicht mehr mit.

Beispiel aus Block 5: ein Vorausblick

Kapitel 39 (Block 5) plugt den Checkout-Totals-Collector, um einen Punkte-Rabatt tatsächlich in die Bestellsumme einzurechnen. Das erfordert ein Plugin: der zurückgegebene Total-Betrag muss vor seiner Verwendung im Checkout aktiv verändert werden - ein Observer könnte den fertig berechneten Betrag höchstens protokollieren, niemals korrigieren.

Entscheidungs-Checkliste

1. Muss der Rückgabewert oder die Argumente einer konkreten Methode verändert werden? → Plugin. Strukturell für einen Observer unmöglich.
2. Reicht "etwas Zusätzliches passiert, nachdem etwas geschehen ist", ohne den ursprünglichen Ablauf zu verändern? → Observer. Einfacher, entkoppelter, beliebig viele unabhängige Abonnenten möglich (Kapitel 29).
3. Dispatcht die Zielstelle überhaupt ein Event? Viele reine Getter und Berechnungen tun das nicht. → Kein Event vorhanden bedeutet: nur ein Plugin (oder eine Preference, Kapitel 40) bleibt als Option.
4. Ist die Zielmethode final oder privat? Plugins können solche Methoden nicht abfangen. → Nur ein Observer (falls ein passendes Event existiert) oder eine Preference kommen infrage.
5. Muss die Ausführungsreihenfolge relativ zu anderem Code exakt und explizit steuerbar sein? → Plugin mit sortOrder (Kapitel 43) - Observer kennen dafür nur die indirekten Mittel aus Kapitel 36.

Gegenüberstellung

• Observer: Publish/Subscribe, beliebig viele unabhängige Abonnenten, kein Rückgabewert-Zugriff, kein explizites sortOrder, läuft synchron und blockierend (Kapitel 29), typisch für "eine Tatsache ist eingetreten, reagiere darauf".
• Plugin: gezielter Interceptor auf genau eine Methode einer genau einen Klasse/eines Interfaces, kann Argumente und Rückgabewert aktiv verändern (before/after/around), explizites, numerisches sortOrder, eng an eine exakte Methodensignatur gekoppelt und damit empfindlicher gegenüber Core-Updates (Block 5 vertieft dieses Risiko ab Kapitel 42).

Damit ist Block 4 abgeschlossen: neun Kapitel, zwei Observer, eine eigene Crongroup, ein Cronjob mit robuster Fehlerbehandlung, ein selbst ausgelöstes Event und eine klare Entscheidungshilfe für die Zukunft. Block 5 beginnt in Kapitel 38 mit Plugins im Detail - beginnend mit before/after/around an sich, bevor Kapitel 39 den ersten echten Plugin-Anwendungsfall dieser Serie umsetzt: den Punkte-Rabatt im Checkout.