In some subcultures of computer programming, action at a distance is a kind of design pattern—specifically an anti-pattern—in which a variable or condition in one part of a program's data structure varies wildly based on difficult_ or impossible_to_identify operations in another part of the program. The most obvious way to avoid such a problem is to make changes in the code at a local rather than a global level.

The term is based on the physics concept of the same name, where particles may be created that cancel each other out. Such particles instantaneously communicate information across space regardless of distance in what Albert Einstein called "spooky action at a distance".

The "action at a distance" pattern may arise because a program component is doing something at the wrong time, or affecting something it should not. It is very difficult, however, to track down what component is responsible. Side effects from innocent actions have put the program in an unknown state, so local data is not necessarily local, and instance data is not necessarily inside an object instance. Communication may be going through channels such as namespaces that are public by nature.

The solution in this particular scenario is to define which components should be interact with which. Communications should occur in events or queues rather than shared state. If events are used, unexpected events are communicated immediately, because any component can evaluate and react to values. If queues are used, the direction of data flow is defined.

From Sins of Perl Revisited (http://www.perl.com/pub/a/1999/11/sins.html) by Mark_Jason Dominus:

Array indices normally begin at 0 because the value of $[ is normally 0; if you set $[ to 1, then arrays start at 1, which makes Fortran programmers happy, and so we see examples like this in the perl3 man page:

 foreach $num ($[ .. $#entry) { print " $num t'",$entry[$num],"' n"; } 

And of course you could set $[ to 17 to have arrays start at some random number such as 17 or 4 instead of at 0 or 1. This was a great way to sabotage module authors.

Fortunately, sanity prevailed. These features are now recognized to have been mistakes. The perl5-porters mailing list now has a catchphrase for such features: they're called "action at a distance". The principle is that a declaration in one part of the program shouldn't drastically and invisibly alter the behavior of some other part of the program. Some of the old action-at-a-distance features have been reworked into safer versions. For example, In Perl 5, you are not supposed to use $*. Instead, you put /m on the end of the match operator to say that the meanings of ^ and $ should be changed just for that one regex.

Catching action at a distance in scalars

 package WhineyScalar; sub new { tie $_[1], $_[0]; } sub TIESCALAR { bless  my $a, shift; } sub FETCH { my $me = shift; $$me; } sub STORE { my $me = shift; my $oldval = $$me; $$me = shift; (my $package, my $filename, my $line) = caller; print STDERR "value changed from $oldval to $$me at ", join ' ', $package, $filename, $line, " n"; } 1; 

Use this with:

 use WhineyScalar; new WhineyScalar my $foo; $foo = 30; # this generates diagnostic output print $foo, " n"; $foo++; # this generates diagnostic output 

Using tie on a scalar, one can intercept attempts to store data, and generate diagnostics to help one track down what unexpected sequence of events is taking place.

Action at a distance across objects

The Law of Demeter states that an object should only interact with other objects near itself. Should action in a distant part of the system be required, the message should be propagated. This minimizes the impact of changes to a program.

Pressure to create an object orgy arises from poor interface design, perhaps taking the form of a God object, not implementing MoveCollectionsOfFunctionsToObjects, or failing to heed the Law of Demeter.

Accumulate and fire situations should be replaced with a command object or whole object arrangement, or a model view controller configuration.

One of the advantages of functional programming is that action at a distance is de-emphasised, sometimes to the point of being impossible to express at all in the source language.

See also

• Accumulate and fire
• God object
• Law of Demeter
• Loose coupling
• Object orgy
• State pattern

The article is originally based on content from the Perl Design Patterns Book.