Pattern(s) sought for avoiding "action at a distance"

Question

I'm working on a complex and very large web application. Some of the classes within said application require execution of various methods in far-away objects, and I am quickly realizing and stumbling into bugs related to the "action at a distance" antipattern.

Example 1: Some of the classes require execution of daily "cleanup" methods, such as reaper() , cleanup() , send_daily_status_messages() , etc.

Example 2: Some classes mutate the app's state, and require a far-away object to perform a refresh() of its own state.

Example 3: Going back to Example 1, some objects spread throughout the app provide various bits of content to send_daily_status_messages() .

To address this, our team has created an Events class that centralizes all of these calls. However we're finding the Events class itself to be a bit too "distant", in the sense that sometimes we make changes in the distributed objects, forget to make changes to the calls within the Events class, and then see bugs.

I'm wondering if there are any better patterns out there?

One thought: For objects to "register" themselves to some sort of dynamic Events class upon initialization. That would keep the invocation code near each object. Objects could maybe even also create different Events?

Lastly, this is for a Perl-based web application that using Moose. So any Perl-specific Moose-friendly recommendations, including CPAN recommendations, would be most appreciated!

Answer 1

The common pattern that sounds like what you're talking about is event dispatch. You can find many different takes on this pattern on CPAN, such as: Event::Distributor , Beam::Emitter , Mixin::Event::Dispatch , Mojo::EventEmitter (which I've extracted to a role ). You have some object which is either an event dispatcher or has an event dispatching role applied to it, and everything can subscribe to events, and when something emits an event all of the subscribers get their callback called.