StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>I find that I often start of my code with a singleton. Even though I know better - singletons like this are basically globals, and we all know globals are bad.</p> <p>But, it is so darn <em>easy</em> to code up a singleton like this, and use it wherever necessary.</p> <p>Often, in a little while - a month or so - I end up switching to the "pass it around" pattern. Usually because what started out as a singleton becomes more than one. E.g. in the stuff I do for a living, a singleton processor_under_test() becomes multiple processors.</p> <p>In your case, ask yourself: what is the chance that your single App, reflected in AppCurrentStatus, will eventually become one of a set of several cooperating apps? If low, the singleton may be the easy way.</p> <p>(In a related vein, think about how many single document apps become multiple documents.)</p> <p>Don't worry yourself about this, about finding the best possible way. Changes like this are just part of programming. Sometimes you flow from singleton to, what could we call it, N-ton. Sometimes back.</p> <p>However, it is worth mentioning two related patterns here.</p> <p>First, when what started out as a singleton becomes an N-ary-ton, you don't need to give up the ease of use of a global singletin right away. Instead, you can create a master singleton, which I usually call something like "environ", that holds the several N-ary-ton objects or references, and probably other stuff besides.</p> <p>Also, if you do choose to pass the object around, you don't necessarily need to pass just the AppCurrentStatus around. Because you will probably eventually need to pass something else as well. Again, I usually pass around something I call an Environmrnt, whivch may have different shapes at different call sites.</p> <hr> <p>Two final notes:</p> <p>(1) I am willing to tolerate the use of singletons in application code that is not a good candidate for reuse. However, I have found that if I am writing code that is likely ever to want to be included in a library and reused elsewhere, then depending on a singleton is bad - because that elsewhere may not want to clutter itself with your singleton(s).</p> <p>Similarly, for some reason I have found it harder to write good unit tests for singleton code. I can't remember all of the details right now, but, consider: how do you test several differeht ways of constructing and destructing a singleton? And you may well want a destructor or finalizer, if for no other reason than when your app shuts down.</p> <p>For these reasons, I often create two classes:</p> <p>The inner class, which in your example I might call AppCurrentStatus. And the outer class, AppCurrentStatus_singleton.</p> <p>Possibly hiding the implementation of the inner class from people who will be using the singleton, but exposing it so that you can write a good set of unit tests. I do this often enough that in C++ I have created some templates that do the easy cases: Singleton.</p> <p>(2) Finally, in case you care about performance, the more parameters that get passed around, the slower. Whereas the singleton global is probably faster.</p> <p>For most programs this is probably a don't care, premature optimization. I just think about that sort of thing since performance is my bread and butter.</p> <p>Related, maintainability: although singletons are globals, and globals are bad, I think that big argument lists for functions/methods are even worse. I'd rather use singletons. But the Paramater Object desiogn pattern may be better.</p> <hr> <p>OK, I lied: another issue in favor of singletons: sometimes you don't have the ability to change all of the code. E.g. sometimes you pass a callback to some library, who eventually calls your code. You may not have the option of adding a parameter to this interface. A singleton can do this.</p> <p>Related: anyone doing callbacks should provide an escape hatch: a generic object reference, or a cookie, that the callback manipulating library passes around, but does not impute semantics to.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload