Articulo de referencia

Acción a distancia (programación informática)

La acción a distancia es un antipatrón en informática en el que el comportamiento de una parte de un programa varía enormemente en función de operaciones difíciles o imposibles ...

La acción a distancia es un antipatrón en informática en el que el comportamiento de una parte de un programa varía enormemente en función de operaciones difíciles o imposibles de identificar en otra parte del programa.

La forma de evitar los problemas asociados con la acción a distancia es un diseño adecuado, que evite las variables globales y altere los datos solo de manera controlada y local , o el uso de un estilo de programación funcional puro con transparencia referencial .

El término se basa en el concepto de acción a distancia en física, que puede referirse a un proceso que permite que los objetos interactúen sin una partícula mediadora como el gluón . En particular, Albert Einstein se refería a la no localidad cuántica como "acción fantasmal a distancia".

Los errores de software causados ​​por acciones remotas pueden surgir cuando un componente del programa realiza alguna acción en un momento inadecuado o afecta a algo que no debería. Sin embargo, es muy difícil determinar qué componente es el responsable. Los efectos secundarios de acciones aparentemente inocuas pueden dejar al programa en un estado desconocido, por lo que los datos locales no son necesariamente locales. La solución en este caso particular consiste en definir qué componentes deben interactuar entre sí. Un diseño adecuado que defina con precisión la interfaz entre las partes de un programa y que evite estados compartidos puede eliminar en gran medida los problemas causados ​​por acciones remotas.

Ejemplo

Este ejemplo, del lenguaje de programación Perl , demuestra un caso especialmente grave de acción a distancia (nótese que la $[variable quedó obsoleta en versiones posteriores de Perl [ 1 ] ):

Los índices de los arrays normalmente comienzan en 0 porque el valor de $[es normalmente 0; si se establece $[en 1, los arrays comienzan en 1, lo que hace felices a los programadores de Fortran , y por eso vemos ejemplos como este en la perl(3)página man :

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

Y, por supuesto, se podía configurar $[a 17 para que los arrays comenzaran en un número aleatorio como 17 o 4 en lugar de en 0 o 1. Esta era una excelente manera de sabotear a los autores de módulos.

Afortunadamente, prevaleció la sensatez. Ahora se reconoce que estas características fueron errores. La lista de correo perl5-porters tiene un término para referirse a ellas: "acción a distancia". El principio es que una declaración en una parte del programa no debería alterar de forma drástica e imperceptible el comportamiento de otra parte del mismo.

Mark Jason Dominus , Los pecados de Perl revisitados [ 2 ]

Acción a distancia a través de objetos

La programación orientada a objetos adecuada implica principios de diseño que evitan la acción a distancia.

La Ley de Demeter establece que un objeto solo debe interactuar con objetos cercanos. Si se requiere alguna acción en una parte distante del sistema, esta debe implementarse mediante la propagación de un mensaje. Un diseño adecuado limita considerablemente las acciones a distancia, lo que contribuye a la mantenibilidad de los programas. La tendencia a crear una orgía de objetos surge de un diseño de interfaz deficiente, que puede adoptar la forma de un objeto todopoderoso , no implementar objetos reales o ignorar la Ley de Demeter.

Una de las ventajas de la programación funcional es que se resta importancia a la acción a distancia, a veces hasta el punto de que resulta imposible expresarla en el lenguaje fuente.

Ser consciente del peligro de permitir acciones a distancia en un diseño, y poder reconocer su presencia, es útil para desarrollar programas correctos, fiables y fáciles de mantener. Dado que la mayor parte del coste de un programa puede residir en la fase de mantenimiento, y que las acciones a distancia dificultan, encarecen y aumentan la probabilidad de errores en dicho mantenimiento, merece la pena esforzarse durante la fase de diseño para evitarlas.

Véase también

Referencias

  1. "Documentación en Perl de la $[variable" .
  2. Dominus, Mark Jason (1999). "Los pecados de Perl revisitados" .