This would seem to preclude possible future flexibility of having two different databases in use. It also complicates understanding the code and debugging since this means that an existing DvdDatabase object could magically start calling a different underlying DVDFileAccess object during its execution whenever another call to the DvdDatbase constructor was performed. What am I missing here?
In his defence if you reading the text I can see what his design aims are, i.e. he's effectively forcing you to always use only one database while not restrict the interface so that its hard to change it in this way later i.e. he's avoiding the singleton pattern so you don't have to get the only instance of the one and only DVD database and he's done this at both a DBClient and DvdFileAccess level with his use of static and check there is only ever one db file (by path) . If he did use the standard singleton pattern and you wanted more than one dvd (flexibilty as you suggest) he'ed have to change the interfaces to the class and he's not gone the generic route has you have to deal with the issues of two files.
Again I see what your both getting at the actual code he's generated for me is at best odd (particularly the static) though not wrong as such but I do take on board his comment.
For me I would have gone for a pure singleton or a pure generic database rather than trying to do a hybrid, i.e. one that works as a singleton now but whose interfaces were easily adapted to generic use. I suspect I'll write a generic class and use it from a seperate a singleton instead.
If I hadn't read the book and just seen the code with no comments, and had no idea of the level of programmer who had implemented it I would have assumed a design mistake (though actually thats wrong).
It is personal preference though and hopefully the examiners are looking for more clear documentation of the design choice rather than only this design is right.
"Eagles may soar but weasels don't get sucked into jet engines" SCJP 1.6, SCWCD 1.4, SCJD 1.5,SCBCD 5
Joined: Jan 22, 2006
I guess what I'm not understanding is why the static is needed at the DvdDatabase layer given that DvdFileAccess only allows one named database open (only one RandomAccessFile). If you didn't have 'database' as static, wouldn't all his goals still be met (one underlying database could be open and no singleton interface)?
I was just thinking the same issue. Why the attribute database (DvdFileAccess) is static in this case? Isn't it that the creation of DvdDatabase that should be static in a single VM (i.e. a single server instance will only have a single DvdDatabase - hence static + once instantiation only). When I looked at the code of the server, it seems the DvdDatabase is indeed created multiple times for multiple client access, in which case multiple DvdFileAccess also created. Plus the RandomAccessFile attribute in DvdFileAccess is not static, so on new construction it always null, while the dbPath attribute is static but not used for checking in the code (I think it was originally using dbPath in the book, which make more sense in this case).
Hi, Good question! I am also reading Andrew's book. Also ReservationManager instance is a statice member in the DvdDatabase, Then the record Map is also declared as static. But I used singleton for both LockManager and DBFileAccess (equivalent to the DvdFileAccess).