Talk:Poltergeist (computer programming)

This doesn't sound very convincing. Just packing all the functionality into said other class may breach the "one class, one responsibility" guideline which I consider essential. Resource waste seems to be a non-issue, too, given a good optimizing compiler (or VM). Maybe someone could give an example of how this anti-pattern looks in practice? Aragorn2 16:13, 27 September 2005 (UTC)[reply]

P.S.: I can think of many very reasonable uses of "short-lived objects used to invoke methods in another more permanent class", e.g. Lock objects in C++.

"Unnecessary resource waste", eh? His metaphor is better than his grammar. And "the typical cause for this antipattern is poor object design" is a very nice vacuous statement. It makes you wonder whether these things deserve encyclopedia articles at all. Can any Joe call something an anti-pattern and have it recorded here? 82.92.119.11 23:42, 1 April 2006 (UTC)[reply]

Can anyone clarify where the difference between a proxy and a Poltergeist lies? I mean, sure, a network proxy *may* keep state (e.g. a socket file descriptor), but if it's e.g. a proxy that allows easily sending messages to the main thread, it may not even need to keep state itself. Uliwitness 12:30, 24 August 2006 (UTC)[reply]

"Maybe someone could give an example of how this anti-pattern looks in practice?"

From my understanding this (debatably) anti-pattern arises from using an object to represent an enum-type structure in languages that don't support it.

For example:

class Class1 {

 function foo() {
   poltergeist = new MyEnumType(data1, data2, ...);
   instanceOfClass2.enumAcceptor(poltergeist);
 }

}

class Class2 {

 function enumAcceptor(MyEnumType anEnumObject) {
   //extract data from anEnumObject
   ...
 }

}

The solution to this "problem" is to simply put the individual items of the enum into the functions definition. Philipgraham 18:17, 21 March 2007 (UTC)[reply]

I think the diagnosis of this as an anti-pattern predates the widespread adoption of functional programming. The definition of this anti-pattern would include all function objects. Avoidance of such objects seems like an outdated design principle.Madbehemoth 18:34, 24 April 2007 (UTC)[reply]