Trying to figure out if this code creates any benefit by using a Singleton

Question

I'm working on a project where one of the co-developers (and previous developers) use a Singleton/Facade for just about every page of class that has a lot of method calls inside of it, but that don't actually maintain the data.

For instance:

public class FooFacade
{
    private static FooFacade m_facade = null;
    private static DataAccessManager m_dataAccessMgr = null;

    public StringBuilder Status {get; set; }

    private FooFacade()
    {
        this.Status = new StringBuilder();
    }

    public static FooFacade getInstance()
    {
        if (m_facade == null)
        {
            m_dataAccessMgr = DataAccessManager.getInstance();
            m_facade = new FooFacade();
        }

        return m_facade;
    }

    public void clearStatus()
    {
        this.Status.Remove(0, Status.Length);
    }

 public void Method1(string value1, int value2)
    {
     // DO SOMETHING
    }


 public List<string> Method2(string value1, int value2)
    {
     // DO SOMETHING ELSE
     // RETURN LIST
    }

Now, I have certain issues with the naming convention and the fact that they have the Singelton inside the same class as the Facade and the fact that the Facade isn't really a Facade. (but that's a whole different conversation).

So my question is whether there really is a benefit from this. The best that the developer could explain is that it is better for memory management since you're not constantly creating and disposing of objects.

Our application is not an enterprise level app and we don't have issues with memory. Anytime the site is slow, it's really due to the database and not the code.

Thanks for your help. I'm a developer who loves to know why to make myself a better developer. Since I can't get it from the developer in words that make sense, I'm reaching out to you guys.

Thanks, Chad

UPDATED Thanks to the comments below, I know that the status is a serious concern as it has a chance of being a huge security flaw. Is there any benefit to using this code in a Singleton when it comes to memory management, speed, etc? Or would it just be easier to instantiate FooFacade every time I need it.

The StringBuilder jumps out to me. It's an example of shared state that you said the class does not have, yet it clearly does. That property and the `clearStatus` method could present challenges. — Anthony Pegram, Jan 09 '12 at 18:48
So if I'm hearing you correct, it's possible that a status message from one user could be displayed to another user? — Cyfer13, Jan 09 '12 at 18:58
Plus added to, cleared, displayed; mix and match of all of the above. Global state is hard. And it sounds like the previous developers discovered a pattern and got overly happy with it. — Anthony Pegram, Jan 09 '12 at 19:06

score 6 · Accepted Answer · answered Jan 09 '12 at 18:53

6

Because your object has an internal state (Status) you are asking for trouble. Specifically, if ever the singleton is used from within multiple threads (for example in a web app) the code will probably just won't work.

Use singletons only if you have classes that have no internal state.

answered Jan 09 '12 at 18:53

Wiktor Zychla

47,367
6
74
106

1

yeah, that is one of the lines that I have issues with. If the DAL has an error, it updates that status message. Yeah, really. No thrown exceptions for him. – Cyfer13 Jan 09 '12 at 18:55

afrischke · Answer 2 · 2012-01-10T00:22:37.133

Is there any benefit to using this code in a Singleton when it comes to memory management, speed, etc? Or would it just be easier to instantiate FooFacade every time I need it.

All an instance of this type contains is a reference to a StringBuilder. Also, there is no heavy lifting going on when a new instance is created (unless DataAccessManager.getInstance() does some nasty stuff behind the scenes). So no, no tangible benefit in terms of memory management, speed etc. I would just instantiate a new instance when I need one. (Or rather: I would try to get rid of this class entirely...)

score 1 · Answer 3 · answered Jan 09 '12 at 21:59

I would save the singleton pattern for things that must exist as a singleton, such as a specific file that is shared between multiple consumers. Singletons usually involve isolating threading issues. However, If you have a class that contains no state and is implemented with the singleton pattern, you have implemented a utility class which can easily become an anti-pattern. While not a good idea, it would have been more performant being a static class with static methods. Static methods remove the need for a null check before calling the method. But as I said in the beginning, leave the singleton pattern for things that must be singletons.

Trying to figure out if this code creates any benefit by using a Singleton

3 Answers3

Linked