OOP Design Advice
 

I'm trying to program a simple daemon that (will eventually) compile in Windows and UNIX. Users will be able to login and have accounts set up, almost like a MUD, but it's not going to be a MUD.

I would like to really try my hand at programming something that's worthwhile of my time and effort, and so I would like to do it <i>right</i> (that's objective obviously)

I thought of having a few objects, namely one for the server listening, the configuration file (loading, saving), database routines (connecting, fetching, modifying information) as well as an object for the users, menus, etc etc.

I need some advice as to a good way of designing this system so that I can use an SQL database as a back end to store information. The trouble is, I know how much a database can bring a computer to its knees. Therefore, I would like to minimize the number of connections and queries to the database.

How do I go about designing each of my objects when a few of them depend on file I/O (be it database or flat-file) to load and save information persistently?

Should I have a database object (with each DB object <hopefully> only have one connection to the database) and have my user/menu objects inherit from it, or should I pass the DB object into each user and menu object ?

Hopefully it wasn't too confusing, but perhaps someone can point me in the right direction or give some sound advice in this matter.

Thanks.

First off, kudos for wanting to do the right thing, instead of just another hack-job. :)

Second, on the database issue, I would go for a singleton design pattern (if you don't know anything about design patterns, look it up on wikipedia.org or something, it's amazing stuff), just make sure that you have one instance of a database object that does all the queries and has a persistent connection.

Third, if you really want to do something right, you begin with design. I would suggest you check out UML and make a couple of use-cases and a class diagram. Personally I always make ERDs and flow-charts as well, because they are more ways of thinking through the problem/situation and class diagrams can quickly become more about the solution.

Fourth, document. I dunno if you've ever seen the movie Memmento (I love that movie, in case you haven't seen it though, it's about a guy with no long term memory), but the guy from that movie should even be able to work with your code. Keep every function nice and short and well documented (in something like phpDoc or JavaDoc maybe?). This will SIGNIFICANTLY help prevent code reuse and save time in the long run.

This is my $0.02 anyway. :)

Databases don't kill a system as much as you might think. Indexing (the software can do this) and good design (you should do this) should help minimize the utilization. Then again, if you're expecting to run many simulataneous users, you might want to consider other options. You might want to consider different storage options for different types of data. For structured data that's not accessed too much, you can throw that in any type of database.

I've read that Berkeley DB is one of the fastest DBs out there, but it's also more limited. Perhaps you can arrange your most common data to fit in a Berkeley DB somehow.

Sorry I couldn't be more helpful. Hopefully you can do some research on Berkeley DBs to see if you can use them.

Regarding your object design, don't worry about how everything connects to the DB. Instead, build some kind of data access object that talks to the DB. Should you take the singleton route, this can be a singleton object. Note that having a singleton DB connection can be slower than having multiple connections, because you can only run one query at a time. Something as simple and quick as a login will have to wait until other queries are finished, instead of running in parallel.

Adding to what RelaX says, you will always do something wrong the first time you program it. This is why there are multiple versions and programming techniques like refactoring. Once you learn how to do it, a better way is almost always found.

So true... which is why OOP and spending lots of time on design is so crucial. In theory, if you do those perfect, then if you find a better way for a method or object to handle it's responsibilities, then you have to spend only a small amount of time to re-implement those methods and objects.

The real problems are changes in the design though. Even with proper OOP, if your design is seriously flawed, then it WILL mean lots of cursing and shouting at the pc trying to right the wrong and you'll probably end up with a real hackjob.

If you are looking to do this cross platform, you might want to consider Java, especially if you are interested in doing proper OO. And, if you are going to do that, you might want to look at building up from an existing framework, such as HiveMind .

Sure, you have some overhead in learning a new API, but remember the zen of Java: To make things simple, you must first make them complex.

Connection Pooling
 

A technique that is used in industry for maintaining as few DB connections as possible is connection pooling. I program primarily in Java, so that is what I am basing this suggestion off of.

If you have a system that requires many small transactions to a database, very few of them are actually run simultaneously. You can have a pool of seemingly very few connections that get shared throughout the application. You have to be very careful to release the connections back to the pool EVERY time, especially when something fails. Otherwise you'll run out of available connections.

Most (all?) of the major web-based applications that are running out there use connection pooling rather than having dedicated connections for each transaction.