The Data class is for one table, that's for sure, because the operation is based on records.
Well, one database can only contain one table, that's ridiculous .
So suppose the database has two tables, then we need two files at least, and we need two distinct Data classes (make sure one Data class corresponding to each file) . Then we need an DAOManager to pick up which Data class (now DAO) to use in RoomServices or CustomerServices. DAOManager must be singleton, that's for sure. But Data class can be more than one, as long as no Data class share the same datafile. DAOManager act as a Factory, so called it DAOFactory.
This design overthrows my previous design since this new assumption makes sense. I chopped off the DataAccessor, and introduced DAOFactory. So it will be easy to add a new table (file) into my design, all changes will be encapsulated in DAOFactory.
SCJP 6 with 93%
Oracle Database SQL Expert with 98%
I have often argued against a singleton for the Data class simply because I don't feel that a single table per database is a good design decision.
One alternative is that recommended by Phil Maquet - he recommended having an effective singleton per table - search for "Multiton" in this forum to see more of his design.
I will say though, that many people pass with a singleton design. One of the Agile principles is "Simplicity--the art of maximizing the amount of work not done--is essential". This is often described various ways, but the reasoning behind it is simple: work that is not needed right now is often wasted work. In concrete terms, imagine if you spend the next 6 months developing a wonderful system where you can have as many databases as you like, with as many tables in each database as you like, all accessible through the Data interface. Then just as you are nearing completion, the business owners choose to put all the data in an Oracle database. That 6 months is now wasted work. This holds true quite often in real life as well: the further you go beyond scope, the more likely that your enhancements will be wasted.
It's really challenging to take SCJD. The assignment must meeting all "must requirements" and must not over-complicated (The simplicity you mentioned).
All the troubles come out from this line saying something about enhancements.
Your user interface should be designed with the expectation of future functionality enhancements, and it should establish a framework that will support this with minimal disruption to the users when this occurs.
None knows what this "future functionality enhancements" would be. May be it implies adding a customer file for the billing step of booking transaction, or may be it just means another button for cancelling a booking.
Simplicity is really not simple. It requires accurant understanding of requirements and a little bit of gambling: chopping off those parts that might be must requirements and at same time might be enhancements out of scope.
No one wants to fail the exam. So actually this incentive influnces my design.