Singleton

saeidw · 2010-08-31T08:05:37+00:00

Here's an interesting design issue I encountered with while working on some code. Let's say your application writes and reads data to and from a database....

xterm

arithma wroteWhat happens if you want to communicate between two databases?
This is not too uncommon, and happens all the time in migration scripts, in manual duplication and so on.
What does a singleton buy you that a global object doesn't? And when you need to make two databases communicate through your script, you can have two of these global objects!
It's almost like magic.

That's totally irrelevant. A singleton doesn't enforce a single database it enforces a single instance of a specific type, you could easily build the singleton in a way to handle multiple databases per data source/context.

db1_a = DBSingleton.Instance<DB1DataSource>();
db1_b = DBSingleton.Instance<DB1DataSource>();
db1_c = DBSingleton.Instance<DB1DataSource>();

db2_a = DBSingleton.Instance<DB2DataSource>();
db2_b = DBSingleton.Instance<DB2DataSource>();
db2_c = DBSingleton.Instance<DB2DataSource>();

The entire theory about Singletons being bad is the issue with developer awareness. If you're aware that you should only instantiate a certain object once, then you do not need to use a singleton though how terrible of a thing it is to enforce it?

P.S.: Globals are generally worse than singletons if we're mentioning strict OO

rolf

xterm wroteNo, that's a stateless approach.

Not sure about that, it contains several variable that change over the life of the instance.
Not sure if you're referring to my code or to PHP anyway.

saeidw

Thanks for the relevant links everyone, I'll read those as soon as I can.
I'm not really having trouble with getting the code to work but I'm just interested in how
others might do the same thing, I want to see the advantages and problems in my own
thinking, and maybe learn something I didn't know.

Here's an example of what I did, forgive the horrible VB.NET, I'm learning the language as I go.

The way I finally settled on implementing it was by placing this object between the database and all the other classes. It speaks SQL to the database, but it communicates with everyone else through DataSet objects. This way, if a class wants to modify the database, it can create a DataSet object and pass it to the appropriate function in the singleton.

I got this idea by reading about Data Access Objects. (I'm not one of those Design Pattern obsessed programmers, I promise, I've just been reading about all these techniques recently :p).

The negative thing I see about this is that my object must either support every possible specific database usage a class might want, or it must be so generic that it can support any database interaction no matter what (I don't know how to do that :p).

So I ended up with a singleton, not so bad but I'll definitely try it another way next time.

xterm

Err made a mistake with a block I wrote I'll correct it later

arithma

@saeidw: Why not drop the singletoness and keep the object as a database connection with facilities?

xterm

rolf wrote
xterm wroteNo, that's a stateless approach.
Not sure about that, it contains several variable that change over the life of the instance.
Not sure if you're referring to my code or to PHP anyway.

Honestly i cannot judge based on what you provided. If you've defined within your app.php that the variable $db yields the same instance every time until disposed, then yes it is a singleton.

Again, the issue with whether or not you can use Singletons goes hand in hand with the context that you're working in. In terms of database if every instance of the accessor you're using creates its own connection pool, then Singleton is necessary, however if the accessors share connection pools, then you don't need to create a Singleton and just new up as many as you want (ofcourse, disposing is necessary).

xterm

saeidw wroteHere's an example of what I did, forgive the horrible VB.NET, I'm learning the language as I go.

Oy! move the instantiation on line 2 to the Instance() function and check if the object is null before newing up or returning it.

Your code would fault up if the object got disposed for any possible reason.

arithma

@xterm: Your example breaks when you need to connect to database sources dynamically (you can't have multiple singletons over a single configuration class).
Anyway, persistent objects need a context anyway, and that context can have the object that manages marshaling into the database that the objects may require for communicating with the database. That eliminates the need for an all engrossing singleton accessible to the whole universe.

xterm

arithma wrote@xterm: Your example breaks when you need to connect to database sources dynamically (you can't have multiple singletons over a single configuration class).

My example is just, well an example. Just because i used generics doesn't mean that it's the only way to go. Remove the generics and pass the type as a string. Better yet, in the .NET context, which is clearly saeidw's case, he could create a singleton based on the connectionString which is flexible enough not only to change databases, but to change providers as well.

I've yet to see a compelling reason as to why using the Singleton pattern where it fits, is a bad idea. Reducing the entire issue to "Being able to access multiple databases" is not a good enough reason to avoid using a screw driver to bolt screws.

arithma

he could create a singleton based on the connectionString which is flexible enough not only to change databases, but to change providers as well

Do we have different definitions for singletons? The pattern designates that a singleton class can have a single instance. How can you parametrize a singleton across a connection string without generics? Without spitting out new objects, a.k.a. a singleton factory.

I've yet to see a compelling reason as to why using the Singleton pattern where it fits, is a bad idea.

The main problem with a singleton is first, it gives the programmer the illusion that they're accomplishing more work (with all the single instance logic and so on). Secondly, it's at least as bad as a constant global variable for exactly the same reasons the global variables are bad (whichever they are).

I've yet to see a compelling reason as to why using the Singleton pattern where it fits, is a good idea. What does it solve that a constant global variable does not? It only hides the hideousness that a programmer is doing anyway.

xterm

arithma wroteDo we have different definitions for singletons? The pattern designates that a singleton class can have a single instance. How can you parametrize a singleton across a connection string without generics? Without spitting out new objects, a.k.a. a singleton factory.

You can always add your own touch to a design pattern. Django for instance, can mislead people into thinking it promotes an MVC architecture, simply because it acts like one where in fact it's more of an M(odel) V(view) T(emplate). Yet it's so close to the MVC architecture in terms of implementation that i bet you anything, you can ask any django developer and he'll tell you it's MVC. Hell, even i say its MVC so that i don't have to explain the reasoning behind MVT.

In our case, we can say it's a Glorified Singleton Factory a.k.a Ginglactory!

arithma wroteThe main problem with a singleton is first, it gives the programmer the illusion that they're accomplishing more work (with all the single instance logic and so on). Secondly, it's at least as bad as a constant global variable for exactly the same reasons the global variables are bad (whichever they are).

I've yet to see a compelling reason as to why using the Singleton pattern where it fits, is a good idea. What does it solve that a constant global variable does not? It only hides the hideousness that a programmer is doing anyway.

Scenario:

You're using a DBContext which provides you with access to the database. Each instance of this context would have it's own connection pool. Instantiating this pool more than once would inherently mean that you're creating more overload on the system. Hence i do need just one instance.

Clearly we both agree that the need for a way to force a single instance is important.

Where you would:

public const DBContext db = new DBContext();

I would:

DBContext db = DBSingleton.Instance();

Difference?

You wrote less, I wrote more.
I can reuse my class in a different application, you'd have to declare globals everytime.

I like potatoes, you like potAtoes.