Poltergeist (computer programming): Difference between revisions

Revision as of 22:16, 28 March 2021

Revision as of 01:24, 23 May 2021

Line 8:

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 [[pattern]] such as [[model-view-controllermodel–view–controller]], or tier-separating patterns such as [[business-delegate]].

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

==See also==

* [[Anti-pattern]]

* [[Factory (object-oriented programming)]]

* [[YAGNI|YAGNI principle]]

==References==