• Advertisement
Sign in to follow this  

Alternative to Implementing Character Class as Singleton

This topic is 466 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

I am implementing the player character of my game as a class, and I only need one instance. I want the code to reflect this "single instance" requirement by allowing only one instance to be made. I'm currently looking into the Singleton pattern; it seems to satisfy my requirements of only one instance, as well as limiting access to the player character data, given the scope in which I would instantiate the class. With that said, there seems to be a substantial debate over the use of the Singleton pattern. So, my question: Is it appropriate to use the Singleton pattern to implement my player character class (of which I only need one instance)? If not, are there any alternatives which meet my requirement for a single instance and limited access to the player character data?

Share this post


Link to post
Share on other sites
Advertisement

You only need one instantiation of a "character"? Is this a "lone wolf running around loose in a maze" type of scenario?

 

No matter. The answer to your question depends on what level of OOP purist you are. The easy answer is, sure, its fine. I'm not going to defend that, it all depends on how important basic tenets of OOP are to you and your application. For a very simple, one off, situation, like a test, I really don't have a big issue with them. They can even make some aspects of security in an application better.

 

The more difficult no, don't use a singleton, depends on how committed you are to adhering to OOP principals, which hopefully is strong. Singletons break basic OOP contracts by tightly coupling your data to your code, break the single responsibility principal, and can cause insidious inheritance issues that are hard to track down. If you have a need to manage the life cycle and state of a single object, sure use a singleton. But you'll develop a serious code smell if you find you're creating more than one. Its best to avoid the situation entirely by creating proper RAII'd & OOP'd objects rather than spending time on creating Singletons.

 

Singletons are an OOP form of Globals, and globals are bad for a variety of reasons in a true OOP design. Best avoided. But-

 

The language is a toolbox. Use a hammer to hit nails. Use a singleton for quickly trotting out a specific test case, or testing an aspect of your design. Use the information gained to design a proper OOP solution.

Share this post


Link to post
Share on other sites
As a _debugging_ aid if you're _really_ worried that someone might accidentally create a second instance, you can use a global/static flag that is set in the constructor and then assert if a second instance is constructed and that flag is already set.

But that's still a terrible idea unless there's a very high chance that someone is going to accidentally create a second instance (meaning your interface design is bad) or there's a very large but hard-to-detect problem with doing so (meaning your implementation is bad).

Share this post


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

  • Advertisement