Poltergeist (computer programming): Difference between revisions

Revision as of 01:15, 16 July 2023

Revision as of 08:27, 8 November 2023

Line 6:

Sometimes, poltergeist classes are created because the [[programmer]] anticipated the need for a more complex architecture. For example, a poltergeist arises if the same method acts as both the ''client'' and ''invoker'' in a [[command pattern]], and the programmer anticipates separating the two phases. However, this more complex architecture may actually never materialize.

Poltergeists should not be confused with long-lived, state-bearing objects of a [[Software design pattern|pattern]] such as [[model–view–controller]], or tier-separating patterns such as [[business- delegate pattern]].

To remove a poltergeist, delete the class and insert its functionality in the invoked class, possibly by [[Inheritance (object-oriented programming)|inheritance]] or as a [[mixin]].

There have been proposed methods in detecting poltergeists in code for refactoring.<ref>{{cite journal |last1=Al-Rubaye |first1=Samer Raad Azzawi |last2=Selcuk |first2=Yunus Emre |title=An investigation of code cycles and Poltergeist anti-pattern |date=24-26 November 2017 |doi=10.1109/ICSESS.2017.8342882 |url=https://ieeexplore.ieee.org/document/8342882/authors#authors}}</ref>

==See also==