Jump to content
  • Advertisement
Sign in to follow this  
lithos

Why is this an Anti-Pattern

This topic is 3191 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

http://en.wikipedia.org/wiki/Poltergeist_(computer_science) Right now I'm using such a thing to create a CollisionResponse object that stores all the information about a collision. The character/NPCs/Whatever receive these objects whenever they have a positive test for the collision. Basically it's a fast way to store a lot of data without making characters/terrain have to store data together and to keep them unlinked from each other as long as possible(multi threading). Also by using the CollisionResponse class this means every object can process collision information how they need to and using completely different methods if need be. I can also add more data to the CollisionResponse class if need be as well without affecting other objects. Only downside is that if I change how physics works I will need to change it for every object that uses a CollisionResponse differently(which would just be Characters/AI, and solid objects) which I would need to do in a pure OO environment anyways.

Share this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by lithos
Right now I'm using such a thing to create a CollisionResponse object that stores all the information about a collision.
If it stores information, then it is not stateless, so it doesn't fit the (rather skeletal) definition you linked to.

Share this post


Link to post
Share on other sites
Quote:
Original post by Sneftel
Quote:
Original post by lithos
Right now I'm using such a thing to create a CollisionResponse object that stores all the information about a collision.
If it stores information, then it is not stateless, so it doesn't fit the (rather skeletal) definition you linked to.

I think he's using a poltergeist to actually create the CollisionResponse object, not that he's worried that CollisionResponse is a poltergeist itself.

A quick trawl of the web doesn't really come up with anything concrete on this anti-pattern though - just hand-wavy explanations and no actual code examples. Since I can certainly see uses for short-lived objects with no state, I'm inclined to believe that this anti-pattern is largely made up by people trying to jump on the (anti)pattern bandwagon.

Share this post


Link to post
Share on other sites
Just ignore this pattern. The guy that thought this up was clearly just some academic, with no actual real world experience to develop a real intuition for what he's talking about.

There's nothing wrong with doing something like this, and it's infinitely better than the alternative he proposes of cluttering another class with members that will be garbage right after your otherwise poltergeist object would be done with.

Share this post


Link to post
Share on other sites
I think the key point is that a "poltergeist" is transitory and stateless. If the poltergeist instance is useful for creating other instances of the class it becomes a "factory" which is a useful design pattern.

I don't think the pattern has anything to do with storing data ("typically stateless"). The wiki page suggest you insert functionality which would suggest adding an init() method, not members. This is probably a good idea for reasons of code maintainability and resource usage (as suggested in the article).

More practically ... if your code is something like:

crm = new CollisionReponseManager(character, terrain);
cr = crm.createCollisionResponse();
crm.destroy(); // Even if you don't get rid of this object do you ever use it again?



then the CollisionReponseManager can be replaced.

From your example it doesn't seem like this is what you are doing...

Share this post


Link to post
Share on other sites
I think the key is that the class is created and destroyed in a shorter timespan than the object it is working on. So it would be like


CollisionResponse *cr = new CollisionResponse();
Initializer *init = new Initializer();

init->InitializeCR(cr);

delete init;

cr->DoSomeStuff();


I am not sure there is a situation in which I would be doing something like this.

Share this post


Link to post
Share on other sites
An example that I can think of is the ProcessStartInfo class from the .NET framework. The purpose of this class is "gather" inputs, and then you call the Start method which gives you a Process that represents the actual process - once the process is running, the ProcessStartInfo is (almost) useless.

Personally, I don't think it's such a big deal. Certainly, doing it like that seems better than having millions of overloads of the Start method for all of the different combinations of options...

Share this post


Link to post
Share on other sites
Quote:
Original post by Codeka
An example that I can think of is the ProcessStartInfo class from the .NET framework. The purpose of this class is "gather" inputs, and then you call the Start method which gives you a Process that represents the actual process - once the process is running, the ProcessStartInfo is (almost) useless.

Personally, I don't think it's such a big deal. Certainly, doing it like that seems better than having millions of overloads of the Start method for all of the different combinations of options...


I don't know .NET but that sounds like a good example, and is probably why this is not a well known anti-pattern. Once some level of complexity is reached (and common sense is probably the best judge of what level thi is,) encapsulating the initialisation in a separate class becomes useful.

Share this post


Link to post
Share on other sites
ProcessStartInfo isn't stateless - it's actually a "Process Factory".
You configure it with the type of process you want to launch and then stamp the cut pedal and out one comes.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!