Re: A few questions about singletons...

In article <M8Rum.245763$ZN.178307@newsfe23.iad>, somebody@cox.net
says...


It's amazing you've made it 16 years and never learned patterns.
Patterns ARE central to solid development. Perhaps you've been using
them and don't even know it. That's cool, but the problem is that
patterns are also a language of architectural designs. When I, as a
lead, say, "Perhaps a template method would be a good implementation of
this," I hope you know what I'm talking about so I don't have to explain
it to you. Same as if I said, "I implemented the controller with a
basic state pattern that emits commands," in a code review--I want
everyone in the room to know that that sentance means because it saves a
good 20 minutes. You've almost certainly run into this pattern and used
it on your own but I'd still have to explain myself to someone that
should already know what I'm talking about. This is, quite frankly, way
more important than being an expert in how to implement them.

People that don't know patterns, at least in a rudimentary sense, are
more difficult to communicate with.

Further, the fact that you never learned them is a BIG red flag. Basic
curiosity should have made you look into them even if you decided they
were useless. That you didn't care enough to know patterns after 16
years indicates a lack of dedication to your field. People that think
they know enough already usually tend not to be the best developers out
there.


This is an orange flag for me. Prefixing class names with C indicates
attachment to hungarian notation. I'd probably pester you about this
choice of name in an interview. It wouldn't pass a code review in my
shop if 'C' stood for "class".


This would be another red flag for me. Use of printf indicates someone
too attached to the all but obsolete C interface. I'd be worried you
use char[] and malloc too. Different environments may be different but
as a pure C++ development team we avoid the C API almost
entirely...exception being the math library. I'd much rather see
"std::cout << xxx"


This is certainly one implementation. An interviewer is probably only
interested that you know what the Singleton is for, why you'd use it,
why you wouldn't, and at least one method to implement it....and if
you're interviewing for an advanced position I'd ask you what the
problems are with your chosen implementation and might ask for an
alternative. One of which is to stick m_pInst as a static variable in
the function that fetches it:

static CSingleton * GetInstance()
{
  static CSingleton * instance = new CSingleton;
  return instance;
}

Any time you use a singleton you have to address conditions specific to
your given problem. Thread safety is certainly a concern in threaded
environments. Most times when you use a singleton you're not actually
worried about when it deletes and how it gets cleaned up. Sometimes you
are.

You should learn more than the Singleton pattern. The Singleton is
probably the most commonly known but most useless pattern out there. As
someone mentioned it is often considered an anti-pattern. There are
actually very few cases when you should be using one. As an interviewer
I'd be much more impressed if you knew and understoond template method,
chain of responsibility, decorator, or proxy. Hell, even the NullObject
is generally more useful. If you could name and explain these I'd be
more confident that you actually know and understand patterns rather
than just learning enough to pass the basic pattern exam.

I do run into people like you and have accepted them in interviews so
long as they are not hostile to patterns. I, perhaps unlike many,
realize that patterns are consequences of the problem and expose
themselves so obviously that anyone good is going to come upon them
independently. When I first learned them I found I'd used many before.
If you don't know the language I might push a bit to see if you might
recognize one or two if I describe them. One very important part of
this though is that you're not too stubborn to accept their usefulness,
or at the very least accept the fact that you'd be required to learn
them.

The problem I'd see in your sample code and your position of not knowing
patterns is that you have some bad habbits to unlearn and some new stuff
that you need to learn. I'd probably hit you hard to see what your
reaction is. People with 16 years of experience are often too britile
and stubborn to adapt and can be, in many ways, a worse hire than an
intern. Frankly, I'd rather hire a green programmer hands down in
almost every case.