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]

This remembers me a conception of factory which is responsible for creating and initialization of the object. Unlike the object constructor, the factory can choose the class or the object being created (as long as the possible classes implement the needed interface). Sometimes static method is used for this purpose, but unlike the single static method factories may have they own hierarchy. This approach is rather frequent in java system libraries and, to my opinion, is useful I would say, the neutrality of this article is disputed. Audriusa 10:50, 19 August 2007 (UTC)[reply]