ReservationsManager

[Sean Keane]

Hi,

I am reading over the Denny DVD sample assignment in the SCJD Exam with J2SE book by Monkhouse & Camerlengo and had a few questions about their ReservationsManager class.

This sample assignment is based around renting out DVD's. In the ReservationsManager class they have a map that maps a String to a DvdDatabase (see reservations static class member in code below). The String is the UPC code of the DVD (a code which is uinque to a DVD) and the instance of the DvdDatabase represents the person who is renting out the DVD.

My first question is about whether there can be multiple copies of a DVD in the system. Because a UPC code is unique to a DVD this implies there can only ever be one UPC code as a key in the map, so only ever one instance of a DVD. Would I be correct in my thinking that this sample application can never have more than one copy of a DVD?

If my thoughts are correct on only a single copy of a DVD existing in the system, then I'm guessing this is the stay close to the real assignment, where for the assignment that involves reserving hotel rooms for example you would never have more tha once instance of the same room !? Would I be correct here in my thinking?

My second question is around the class used as a value in the map. It may be hard to give feedback on this without more context about the entire application itself. But just throwing it out there...The UPC code is used as a key in the map, this seems intuitive to me. But the value in the map, an instance of the DvdDatabase class, seems a little non-intuitive. This value in the map is meant to represent a person who has rented out a DVD. When you go look at the class associated with this value you see it is called DvdDatabase - this class name doesn't really convey what it is meant to represent. Is DvdDatabase just a poorly chosen name, or should a different entity exist in the application to represent a renter of a DVD? I've inserted a trimmed out version of the DvdDatabase below.


Cheers,

Sean.

[edit by Roberto Perillo]Please avoid posting complete code snippets, even if they are from a book. Instead, try to resume your question in a textual way or with small pseudo codes.[/edit]

[Sean Keane]

Just to follow on from the questions above....

This ReservationsManager class is used as the operation to find a record and rent it is not atomic in this sample application. If one were to go down the route of making the data class a singleton and all of its methods synchronized, could you also make the operation of retrieving a record and renting it atomic, and therefore do away with the need for the ReservationsManager?

One of the arguments posed in the book for not making the retrieval and rent operation atomic is to exploit the use of their thick client. This to me actually seems like a bad idea. One of the ideas behind using the MVC pattern is that you can easily stick in a different viewer and it will work easily with the existing model and controller. So this to me would be an argument for making the operation atomic, to allow for someone who wants to add a thin client at a later point? Seem sensible?

[David Byron]

Sean Keane wrote:Would I be correct in my thinking that this sample application can never have more than one copy of a DVD?

Have you run the sample app to find out? Short of that, have you considered the signature of addDvdRecord in the table model?

But the value in the map, an instance of the DvdDatabase class, seems a little non-intuitive. This value in the map is meant to represent a person who has rented out a DVD. When you go look at the class associated with this value you see it is called DvdDatabase - this class name doesn't really convey what it is meant to represent. Is DvdDatabase just a poorly chosen name, or should a different entity exist in the application to represent a renter of a DVD?

I don't know whether the naming and usage of that class are a bit of misdirection to obscure the relationship between the sample assignment and the real assignment. If I were writing such an app, I would use a DvdDatabase class to represent the database and (if there were renter accounts) I would associate particular renter entities with particular instances of the DVD.

[Sean Keane]

Hi David, thanks for the reply. Nope, I haven't run the application yet. I'm just working my way sequentially through the book and address issues I don't understand as I hit them. I'm pretty sure based on the code that you can only ever have one copy of a DVD, I was just outlining my thinking leading up to the question of "why only one copy"? I suspect only one copy is allowed to keep close to the idea of the real assignment, just wondering what others thought.

If I were writing such an app, I would use a DvdDatabase class to represent the database and (if there were renter accounts) I would associate particular renter entities with particular instances of the DVD.

That was my thinking too. Although, one thing I was wondering about was whether the book uses separate instances of the DvdDatabase for a certain reason. I was thinking that maybe I was missing something here?

Anyone any thoughts on the idea of not making the retrieval and rent operation atomic?

[David Byron]

Sean Keane wrote:Hi David, thanks for the reply. Nope, I haven't run the application yet. I'm just working my way sequentially through the book and address issues I don't understand as I hit them. I'm pretty sure based on the code that you can only ever have one copy of a DVD

Here's the Denny's DVD GUI:

[Sean Keane]

Ooops, looks like my reading of the code was wrong, must take a re-read.

[Sean Keane]

Thanks for the screenshot David. I don't know what I was thinking - or more to the point I probably wasn't thinking!!!

You can of course have multiple copies of a DVD. Setting the number of copies using the set setCopy(int) method in the DVD class.

The ReservationsManager class is purely for locking the DVD record for whilst it is being modified by a client - so of course there is a one-to-one mapping from dvd to client, as you only want one client to hold the lock on a dvd at a time, as you only want one client to be able to modify a dvd record at a time.