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.
You'd have a database connection open and you would issue queries to the database,
either SELECTs, INSERTS, or UPDATEs, etc.
The application is big and you have to do this in lots of places (multiple classes, for example)
to obtain the desired functionality.
The downside is all your modules now have ugly database interaction code, so what's the best
way to keep this database logic separate from your application logic?
The method I'm using is by introducing a database interaction object that handles all the SQL,
and presents the data in a different form to other objects. The users of the object can get information
and update it without having to deal with the database directly.
But since database consistency is important I decided to only allow one instance of this object
to exist in my application. That is, I implemented the
Singleton desing pattern for my database object.
Now
there are lots of arguments about Singletons being bad OO design. The problem is, I can't come up with a different way of separating all that database code. You can tell I'm not very experienced when it comes to this stuff :).
Is it even useful to want the database code separate from other modules? I'd like to read your approaches to solving similar problems and your experiences with the singleton pattern and the woes of global state!