En Programación orientada a objetos el antipatrón de diseñopoltergeist 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ónfuncional, 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.
Antipattern poltergeists by Sourcemaking Teaching IT Professionals
Development Antipatterns poltergeists
Datos:Q7226038
Agosto 04, 2021
poltergeist, informática, programación, orientada, objetos, antipatrón, diseño, poltergeist, clase, objetos, corta, duración, normalmente, estado, utiliza, para, realizar, inicialización, para, invocar, métodos, otras, clases, definición, original, michael, ak. En Programacion orientada a objetos el antipatron de diseno poltergeist es una clase de objetos de corta duracion normalmente sin estado que se utiliza para realizar la inicializacion o para invocar a los metodos de otras clases La definicion 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 duracion Como consecuencia el codigo es mas dificil de mantener y hay un desperdicio de recursos innecesario La causa habitual de este antipatron es un pobre diseno de objetos Las clases poltergeist se pueden identificar por su nombre A menudo se llaman manager controller start process etcetera A veces las clases poltergeist demuestran la necesidad de una arquitectura mas compleja Por ejemplo un poltergeist surge si el mismo metodo actua como el cliente y el invocador en un patron de comando y el programador separa las dos fases Sin embargo esta arquitectura mas compleja puede que nunca llegue a materializarse Sin embargo a traves del paradigma de programacion 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 patron de diseno Es el punto de vista de la programacion orientada objetos la que confunde esta propiedad con poltergeists en los casos en los que la arquitectura es mas compleja o mejor dicho mas funcional No se debe confundir con objetos de larga duracion que almacenan el estado de un patron como es el caso de Modelo vista controlador que traspasa el flujo de informacion 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 Indice 1 Consecuencias 2 Solucion 3 Vease tambien 4 Enlaces externosConsecuencias EditarProliferacion de clases Clases con poca duracion sin estados y pocas responsabilidades Complejidad excesiva Dificultad de comprender la arquitectura del programa las asociaciones de clases y las llamadas que se realizan entre ellas Analisis y diseno 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 Solucion EditarEliminar 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 Vease tambien EditarAntipatron de diseno Patron de diseno Modelo vista controladorEnlaces externos EditarAntipattern poltergeists by Sourcemaking Teaching IT Professionals Development Antipatterns poltergeists Datos Q7226038Obtenido de https es wikipedia org w index php title Poltergeist informatica amp oldid 117459156, wikipedia, wiki, leyendo, leer, libro, biblioteca,
