This week's book giveaway is in the OCPJP forum. We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line! See this thread for details.
Actually, this question appears to have already been answered in the topic entitled "Data class and facade"... Sorry, should have read first!
This isn't really a mater of life or death question, but I was hoping I could have your opinions anyway. In the data class, it strikes me that there are basically 2 primary concerns (reading and writing blocks of data), and that the locking mechanism is just there to ensure that these things happen safely.
Create, update and delete all write blocks of data to the database file. Find and find by criteria read blocks of data. A lot of the code in these methods will probably be the same.
So I was thinking, why not have a generic, private read method and a generic private write method, each of which is called with a set of specialized parameters by the methods in the interface to do only that particular job (i.e. to tell it what to write or read and where), to avoid code duplication?
But then I noticed that some of the read and write methods throw different exceptions. so which of the following should I do:
1. Just have implementations of the methods in the interface, which do everything required for their own job entirely, and don't have any generic private methods. This might involve some code duplication.
2. Work out whether security, record not found or duplicate key exceptions need to be thrown and throw them in the implementations of the interface methods, which then call the generic private read and write methods.
I have to say I'm inclined towards 2, and accept that this question probably wasn't worth asking, but would like to hear any opinions if anyone has any?
Champion, in my opinion, this is more of an API decision. I'd say that, as long as everything is done correctly beneath the API (which is the interface provided by Sun), then it is really up to you. Of course, the less duplicate code, the better. So, if you are able to create generic methods and ease the implementation of the Data class, go ahead! And, also, try to avoid procedural code.