A New Observer Pattern: Bidirectional Signals from the Emitter’s Perspective in PHP Morteza 5 min read · Aug 23, 2025 -- Listen Share
Press enter or click to view image in full size php-repos’s observer pattern
Introduction: Shifting the Observer Perspective
In software, the traditional observer pattern is often designed with the observer in mind: an event happens, like a user logging in, and a handler — say, a logger — reacts by recording it. This perspective assumes the observer (the handler) is the primary actor, catching events like a net catches fish. In frameworks like Laravel, this is evident: when a PodcastProcessed event triggers a SendPodcastNotification , the focus is on the notification system reacting to the event. But ask yourself: is it the podcast processing code that wants to send a notification, or the notification system that cares about the podcast being processed? In a one-directional world, this distinction seems trivial—events fire, observers react, and the emitter moves on.
Yet, real-world business scenarios rarely work this way. When submitting a sale order, the code might announce its intent (a plan) and expect feedback, like a signal to cancel if inventory is low. Or a library might ask whether to use Postgres or MySQL, adapting based on a response. These cases demand a conversation, not a monologue. The Observer package in PHP redefines the observer pattern by shifting the perspective to the emitter — the code dispatching the signal. From this viewpoint, signals (events, plans, inquiries, messages, or commands) can elicit counter-signals that influence the emitter’s flow, creating a bidirectional dialogue. This article explores this new mindset, its PHP implementation, and practical examples that bring dynamic, business-driven workflows to life.
The Mindset: Signals from the Emitter’s Perspective
Traditional observer patterns, like Laravel’s, treat events as announcements for observers to handle passively — loggers log, notifiers notify. But this observer-centric view limits flexibility. What if the code dispatching the signal needs feedback to adjust its actions? Imagine planning to throw a stone at a window: you announce your intent (a Plan signal), and an observer shouts, “Stop!” (a Command signal), prompting you to drop the stone. The emitter (you) remains the focus, dispatching signals and responding to counter-signals without needing to know who the observers are.
In the Observer package, the emitter’s perspective drives the system. The current code dispatches a signal — be it an event ( UserLoggedIn ), a plan ( SaleOrderPlan ), an inquiry ( ConfirmationInquiry ), or a command—and can receive counter-signals (e.g., a CancelOrderCommand ) that alter its flow. This bidirectional approach mirrors real-world business needs, where actions are proposed, feedback is given, and decisions adapt dynamically, making it ideal for complex, interactive applications.
Core Concepts
The Observer package is built around signals and handlers, leveraging PHP’s dynamic features to create a flexible, emitter-focused system.
... continue reading