Re: Passing Pointers -- where to delete them
On Mar 3, 7:49 am, "jason.cipri...@gmail.com"
<jason.cipri...@gmail.com> wrote:
On Mar 3, 1:24 am, Ian Collins <ian-n...@hotmail.com> wrote:
jason.cipri...@gmail.com wrote:
On Mar 3, 12:37 am, Arv <arvind.b...@gmail.com> wrote:
Because when I use new inside the singleton's getInstance
method, I am not sure when to delete it, since it is a
static member, i am not sure putting the delete in the
destructor would help. Should I have another method
called resetInstance or something?
Well, if it's a singleton, why would you want to reset it? ;-)
Unit tests - you would want the object reset before each test.
Maybe. But you need to be very careful when using singletons
in an application that you are eventually going to be doing
unit testing on; especially if your singleton becomes too
monstrous and starts to contain information used in many
unrelated situations.
That's a design error. Just don't do it. There's no law that
says that an application cannot have more than one, unrelated
singleton.
For one, your unit test code couldn't be completely
self-contained, in that you have to modify the singleton's
code to generate "fake" states. So if you were performing many
different test cases, the singleton would have to be aware of
the cases. Also, making sure that your simulated application
states *do* in fact represent the state you want to test is a
task that may require testing in itself, because you end up
having to fudge all of the singleton's data to make it
completely valid when in fact you are testing a part of your
code that uses only a very small subset of it.
I usually avoid singletons when I know I'm going to have to do
detailed unit testing
Is there *ever* a case when you don't have to do detailed unit
testing. It's a necessary (but not sufficient) condition for
reliable software.
-- not because it's necessarily a bad, evil thing but because
I find it much easier to keep everything separate than lumping
it into a singleton class (which, even if I try not to "lump
everything together", the tendency is there -- perhaps it's
just a personal flaw). If you can design the software with
unit testing in mind from the start, you can keep the
components a bit more isolated, and therefore easier to test.
I find when I use a singleton it starts to blur the lines
between different parts in my application, just by it's
nature.
That's a curious observation. Most of my singletons are in
components. They can't lump things together, because they don't
know about anything else. At the application level, I'll more
often use a local variable in main, rather than a singleton.
In any case, I shouldn't have said "well, if it's a singleton,
why would you want to reset it?";
I'm not sure. It depends on what you meant be "reset it". If
you meant "delete the object and create a new one", then it's
not a singleton if you do.
because it's more a matter of personal taste, I guess, and I
try not to show bias about these kinds of things. But now that
the cat's out of the bag: I do not like singletons very much.
I have never found myself in a situation where there wasn't a
better way.
Like most things, they can be overused, but a few special cases
do occur to me. I use at least two regularly: one for "program
state" (which will define the return value of main in the end),
and one for the command line---the "options" are static
variables which enrol with it, and are automatically processed
when the singleton object is passed argc and argv. My
configuration file data is usually a singleton as well, as is
the log manager.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34