I thought singletons were "Evil"? [modified]

[venomation]

I try not to use global values as I belive that dependancys can be designed in a way that it should be dependant on as few objects as possible howeever I am making a small game and require some behavioural structure and came up with this:

public sealed class EnterMineAndDigForGold : IState<Miner>
{
static readonly EnterMineAndDigForGold _instance = new EnterMineAndDigForGold();

    public static IState<Miner> Instance
    {
        get
        {
            return \_instance;
        }
    }

    public  void Enter(Miner owner)
    {

        if (owner.Location != LocationType.Mine)
        {
            //Change location if minor is not in the mine
            owner.Location = LocationType.Mine;
            Console.WriteLine("Walked into the mine");
        }
    }

    public  void Execute(Miner owner)
    {

        owner.AddToGoldCarried(1);
        Console.WriteLine("Picked up some gold");
        owner.IncreaseFatigue(1);
        Console.WriteLine("Getting more fatigued");

        if (owner.PocketFull)
        {
            //change state to visit bank
        }

        if (owner.IsThirsty)
        {
            //change state to get a drink
        }
    }

    public  void Exit(Miner owner)
    {
        Console.WriteLine(owner.GetType().Name + " Is leaving the mine");
    }
}

Which I have been learning from an AI book have learnt so far. Is this ok to do?

modified on Tuesday, June 15, 2010 6:10 AM

[Lost User]

"Global variables" were considered "evil", mainly because of the abuse - Singletons are not inherently evil. Imagine people setting boolean flags to simulate communication between parts of the application :)

I are Troll :suss:

[Luc Pattyn]

Eddy Vluggen wrote:

Singletons are not inherently evil.

Unless there are too many of them. :)

Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]

---

Nil Volentibus Arduum

---

[Lost User]

Luc Pattyn wrote:

Unless there are too many of them

That would be confusing. It would become evil if you'd try to justify it by calling it obfuscation :)

Quoad vos spirum, vos sperum? :suss:

[David Skelly]

One thing to note about this example is that it's not a singleton. It's a global property called Instance that is accessed via the EnterMineAndDigForGold class. The key point about a singleton is that there is only one instance at any point in time and there can never be more than one. There is nothing stopping me from ignoring the Instance property on EnterMineAndDigForGold and creating as many instances of EnterMineAndDigForGold as I want. In order to make this a singleton you would need to make sure that no-one can create any instances of EnterMineAndDigForGold other than the one created and held as the static variable _instance. The easiest way to do this is to make the constructor for EnterMineAndDigForGold private. That will stop any other class from creating one of these. To be honest, looking at your class I don't think it really matters because your EnterMineAndDigForGold class doesn't have any instance state so it doesn't matter whether you create a new one every time, or share one around, or make all the methods static so that you never need an instance at all.

[LimitedAtonement]

I was thinking that would be the one case (obfuscation) of good justification for too many globals.

In Christ, Aaron Laws http://ProCure.com

[PIEBALDconsult]

Singletons are unnecessary (though not necessarily evil) in C#, especially since the advent of static classes. Only use singletons in lesser languages; like C++.