Talk:Poltergeist (computer science)
From Wikipedia, the free encyclopedia
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)
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)
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)
"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)
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)
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)
"Neutrality here at Wikipedia is all about presenting competing versions of what the facts are. It doesn't matter at all how convinced we are that our facts are the facts. If a significant number of other interested parties really do disagree with us, no matter how wrong we think they are, the neutrality policy dictates that the discussion be recast as a fair presentation of the dispute between the parties." - while you disagree, you do not give any indication a significant number of other interested parties also disagree. There is nothing here than goes against neutral point of view. Perhaps a better comment would have been that shortlived stateless objects can be useful workarounds for working in languages that do not support common programming constructs such as enums, static data or constants. Give examples of such languages. —Preceding unsigned comment added by 12.168.81.98 (talk) 12:54, 13 September 2007 (UTC)
- So, then, the article is not neutral, because it presents Poltergeists as an antipattern, but all the dissenting views are here on the talk page. mike40033 (talk) 02:35, 17 January 2008 (UTC)
-
- Some of the dissenters should put their examples on the main page, and the intro should be edited to remove the assertion that this is always an anti-pattern. Something like:
- Some people consider the Poltergeist an anti-pattern, while others see it as a useful work-around for use in languages that do not provide certain features, e.g., enumerated types or function objects. Over-use of this technique should be avoided, but it can be useful fill-in in cases where no better mechanism exists.
- Once that is done, the "disputed" template can be removed. Bgoldnyxnet (talk) 20:16, 19 March 2008 (UTC)
- Some of the dissenters should put their examples on the main page, and the intro should be edited to remove the assertion that this is always an anti-pattern. Something like:
