Action at a distance pattern

In computer programming, Action at a distance pattern is one of design patterns.

Problem: Someone is doing something at the wrong time, or stomping on something they shouldn't. Problem is, there is no way to track down who or where. Local data isn't local, instance data isn't inside an object instance. Side effects from innocent actions are putting the program in an unknown state. Less innocently, communication may be intentionally going through channels, such as namespaces, that are public by nature.

Solution: Decide who should be talking to whom. Move communications to events or queues rather than shaded state. Using events, if some unexpected happens, everyone knows right away, because they have a chance to check values and react immediately. Using queues, at least everyone knows which way the data is flowing.

From physics, where particles may be created that cancel each other out - such particles instantianiously communicate information across space reguardless of distance in what AlbertEinstien called "spooky action at a distance".

From http://www.perl.com/pub/a/1999/11/sins - 11 deadly sins of Perl by MarkJasonDominus:

//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 17 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.// - http://oreilly.com

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;

[XXX untested code]

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, we can intercept attempts to store data, and generate diagnostics to help us track down what unexpected sequence of events is taking place.

Action at a Distance Across Objects

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

Preasure 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.

AccumulateAndFire situations, where should be replaced with a Command object[?] or Whole object[?] arrangement, or a Model view controller[?] configuration.

The article is originally from Perl Design Patterns Book.

---

See also: Loose coupling[?], Accumulate and fire, Object orgy[?], Law of Demeter, State pattern, God object[?]