On the /r/php subreddit frm Reddit.com, phpdevster proposes an interesting opinion - that an event system, set up with a listener and defined events, has become more of an anti-pattern in its most common implementation.

If events are only meant to be additional functionality that ALWAYS ALWAY ALWAYS should happen after a primary action is taken, how often is code really that absolute? Why are events not implemented in more flexible ways by frameworks? - that is implementing some inversion of control which would allow callers to determine which listeners would be relevant to the given context.

He illustrates his point with an example user registration system that fires a "user-was-registered" event that, in turn, fires off a series of events via a listener. He points out a pretty large flaw, though. While the functionality involved in the event is decoupled (the event itself), the behaviors defined by that event are not. Comments on the post offer some different options and solutions to the same problem including:

• Further decoupling of the eventing process
• Using objects with settable properties rather than just event name strings
• The idea of using an "event store" to handle decoupling rather than more immediate code-based solutions

Have some thoughts of your own on events and decoupling? Go over and share them too.