Poltergeist (informática)

En Programación orientada a objetos el antipatrón de diseño poltergeist es una clase de objetos de corta duración, normalmente sin estado, que se utiliza para realizar la inicialización o para invocar a los métodos de otras clases. La definición original es de Michael Akroyd en la Object World West Conference de 1996:

"Como un poltergeist que aparece y desaparece misteriosamente, lo mismo ocurre con el objeto de breve duración. Como consecuencia, el código es más difícil de mantener y hay un desperdicio de recursos innecesario. La causa habitual de este antipatrón es un pobre diseño de objetos."

Las clases poltergeist se pueden identificar por su nombre. A menudo se llaman "manager_", "controller_", "start_process", etcétera.

A veces, las clases poltergeist demuestran la necesidad de una arquitectura más compleja. Por ejemplo, un poltergeist surge si el mismo método actúa como el cliente y el invocador en un patrón de comando, y el programador separa las dos fases. Sin embargo, esta arquitectura más compleja puede que nunca llegue a materializarse. Sin embargo, a través del paradigma de programación funcional, la existencia de lambda permite una consecuencia similar sin las eventuales desventajas que se le atribuyen, de tal forma que el poltergeist es el propio patrón de diseño. Es el punto de vista de la programación orientada objetos la que confunde esta propiedad con 'poltergeists' en los casos en los que la arquitectura es más compleja (o mejor dicho, más funcional).

No se debe confundir con objetos de larga duración que almacenan el estado de un patrón como es el caso de Modelo-vista-controlador, que traspasa el flujo de información entre las tres clases principales.

Para eliminar un poltergeist, se debe de eliminar la clase llamadora y tratar de insertar su funcionalidad dentro de la clase invocada mediante herencia.

Consecuencias

Proliferación de clases.
Clases con poca duración, sin estados y pocas responsabilidades.
Complejidad excesiva. Difícultad de comprender la arquitectura del programa, las asociaciones de clases y las llamadas que se realizan entre ellas.
Análisis y diseño de modelo inestables.
Pobre funcionamiento del sistema. Se generan instancias y se realizan llamadas innecesarias.
Dificultad de ampliar el programa y de realizar un buen mantenimiento.

Solución

Eliminar clases externas, que no tengan relevancia, clases transitorias y operacionales (Init, Manager, Controller, etc).
Eliminar otras clases con poco tiempo de vida y carencia de responsabilidades.

Véase también

Enlaces externos

Datos: Q7226038