Action at a distance (programação de computadores).

Action at a distance (ação à distância) é um antipadrão na ciência da computação no qual o comportamento de uma parte de um programa varia drasticamente com base em operações difíceis ou impossíveis de identificar em outra parte do programa.

A maneira de evitar os problemas associados à action at a distance é um bom design, que evita variáveis globais e altera dados apenas de maneira controlada e local, ou o uso de um estilo de programação puramente funcional com transparência referencial.

O termo é baseado no conceito de ação à distância na física, que pode se referir a um processo que permite que objetos interajam sem uma partícula mediadora como o glúon. Em particular, Albert Einstein referiu-se à não-localidade quântica como "ação fantasmagórica à distância".

Bugs de software causados por action at a distance podem surgir porque um componente do programa está fazendo algo na hora errada ou afetando algo que não deveria. É muito difícil, no entanto, rastrear qual componente é o responsável. Efeitos colaterais de ações inofensivas podem deixar o programa em um estado desconhecido, de modo que dados locais não são necessariamente locais. A solução nesse cenário específico é definir quais componentes devem interagir com quais outros. Um bom design, que define com precisão a interface entre as partes de um programa e que evita estados compartilhados, pode eliminar em grande parte os problemas causados pela action at a distance.

Este exemplo, da linguagem de programação Perl, demonstra um caso especialmente grave de action at a distance (observe que a variável $[ foi descontinuada em versões posteriores do Perl):

Os índices de arrays normalmente começam em 0 porque o valor de $[ normalmente é 0; se você definir $[ como 1, então os arrays começam em 1, o que deixa os programadores Fortran felizes, e assim vemos exemplos como este na man page do perl(3):

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

E, claro, você poderia definir $[ como 17 para que os arrays começassem em algum número aleatório, como 17 ou 4, em vez de 0 ou 1. Essa era uma ótima maneira de sabotar os autores de módulos.

Felizmente, o bom senso prevaleceu. Hoje reconhece-se que esses recursos foram erros. A lista de discussão perl5-porters agora tem um bordão para tais recursos: eles são chamados de "action at a distance". O princípio é que uma declaração em uma parte do programa não deveria alterar drástica e invisivelmente o comportamento de alguma outra parte do programa.

A programação orientada a objetos bem feita envolve princípios de design que evitam a action at a distance.

A Lei de Deméter afirma que um objeto deve interagir apenas com outros objetos próximos a ele. Caso seja necessária uma ação em uma parte distante do sistema, ela deve ser implementada propagando uma mensagem. Um bom design limita severamente as ocorrências de action at a distance, contribuindo para programas fáceis de manter. A pressão para criar uma object orgy resulta de um design de interface ruim, talvez assumindo a forma de um God object, da não implementação de objetos de verdade ou da falta de atenção à Lei de Deméter.

Uma das vantagens da programação funcional é que a action at a distance é menos enfatizada, às vezes a ponto de ser totalmente impossível de expressar na linguagem de origem.

Estar ciente do perigo de permitir a action at a distance em um design, e ser capaz de reconhecer a presença da action at a distance, é útil para desenvolver programas corretos, confiáveis e fáceis de manter. Dado que a maior parte do custo de um programa pode estar na fase de manutenção, e que a action at a distance torna a manutenção difícil, cara e propensa a erros, vale o esforço de evitá-la durante o design.