Talk:Poltergeist (computer programming)

Untitled

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++.

Poltergeist is a workaround, between Anemic Domain Model and Visitor. The issue with Poltergeist is lack of control over state, much like a public variable can be touched by any code. A Proxy is a reference and does not change the state of the referenced object. — Preceding unsigned comment added by 77.173.226.152 (talk) 11:30, 25 February 2021 (UTC)

"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)

Agree. The factory frames it in a positive way, so I added it to the "See also" section on this page. Avindratalk / contribs 22:44, 28 March 2021 (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)

Hello I was reading this interesting article to know bad practices regarding software and is again very very interesting. Now when I landed into this article about Poltergeist anti-pattern I really became dubious about it. I mean how can this be an anti-pattern? For what I understand in the article is about creating short lived data-container objects. Now that happens a lot in Object oriented language by the mere fact of base libraries for instance in java or .net require objects all the time and many other libraries possibly built by somebody else. I believe that is a side effect of OOP. Now I would like to know about what is exactly a Poltergeist (given the fact that you must do it that way or no other way) and how I can avoid such anti-pattern. And why is (quoting the article) "unnecessary resource waste". Please while writing it keep in mind the object resurrection that happens in the .net framework that reduces a lot such a waste. Ok there is some waste but I believe the benefits are bigger than the drawbacks threfore I have a lot of doubts about considering bad practice. And if I'm wrong please write why. I'm really interested into this to not develop bad practices. waldoalvarez00 —Preceding unsigned comment added by 201.220.215.13 (talk) 08:34, 6 August 2008 (UTC)

I took it that this anti-pattern deals with things like this:

Class WidgitMaker{
  public:
    Widgit New(){
       New Widgit newWidgit;
       newWidgit.doinitializy_stuff();
       moreinitting( newWidgit );
       return newWidgit;
}

The solution being, of course, that this sort of thing belongs in Widget's constructor. If so, maybe an example like this belongs in the article proper.Robbak (talk) 05:04, 20 January 2009 (UTC)

I have to agree with the dissenters. In particular, a more accurate wording of It is considered an anti-pattern would be It has been called an anti-pattern by one person, which some other people uncritically adopted. Like almost every pattern, the use of short-lived objects that initialize other objects has its valid applications. And like almost every pattern, it can be used wrong. Get over it.

The very general claim about being bad design being a typical cause is a confession of failure, as is the allegation that anti-patterns can be identified by the name of a class.

To give an example, initializing audio hardware typically takes, for whatever reason, from 0.2 to 0.4 seconds on a desktop computer. There is not much one can do to make it any faster, either. It is thus perfectly acceptable (and indeed a much more intelligent design) to instantiate a short-lived object which has no other duty than to spawn a thread (which blocks on the initialization), and return another object upon joining the tread. This technique can reduce the startup time of some applications by 50-75%.

The concept of futures is nothing else but a standard for poltergeists, if you look at it from that point of view. Which means, since a poltergeist is considered an anti-pattern, futures are anti-patterns. Go, and tell the C++0x committee that they're all idiots who advocate poor design. I'm curious about the answer. — Preceding unsigned comment added by 92.192.34.72 (talk) 11:05, 18 July 2011 (UTC)