(B&S) I Don't Think I Need Any Statements In Implemented createRecord/deleteRecord

[Bob Nedwor]

Ranchers,
Tell me if I am wrong but it appears that these methods are left over from a previous format of the Exam based on the SCDJ FAQ. I will still implement them in my Data.java to meet the requirements, but why would I need any statements in those methods? They will basically be stubs with comments.

Most of what I have read in this forum on this issue leans toward the "don't try to provide extra functionality" rule. Furthermore, I am just trying to safely pass the Exam and get my SCJD. I don't even care about my score, as long as I pass. None of the "must"s provide for the user to be able to delete or create records.

Am I going down the wrong road? In order for my project to be accepted, will I have to put code in these methods that actually results in creating and deleting records from the datafile?
Thanks so much for any advice on this.

[ February 19, 2006: Message edited by: Bob Nedwor ]
[ February 19, 2006: Message edited by: Bob Nedwor ]

[Eiji Seki]

Hmmm good point, but I'm not sure you can leave these methods out. If your own class is used by automatic systems to populate a test data base, you will fail automatically. O_o

[Bob Nedwor]

Thanks Eiji, but I lost you. I saw nothing in my instructions.html about having to provide for any such scenario (populating a test database). Can you give me an example? Is there something in your instructions.html that leads you to believe that this is a "must" over in your project?

I should add that I was given a datafile that is already populated with records to be used. Weren't you? Thanks for any clarification.
[ February 19, 2006: Message edited by: Bob Nedwor ]

[Eiji Seki]

Some variations of the specification do not provide a data file. It will be generated later by the examiner or a ready one will be used (on their side).

Well, my spec states clearly that my data access class must implement the DBMain interface. If you take a look at the standard Java classes and interfaces, all methods in a interface are be implemented, with the exception of the ones that throw an UnimplementedOperationException (or something like that). BUT these methods have a very important description on their interface: optional.

I don't know, I really wouldn't take such chances. Mostly because implementing such methods are not hard at all.

Also, an advice: even if you don't care about your grade (I don't as well), just make sure you get as many as you can since they might be the difference between passing or not.

[Bob Nedwor]

Eiji:

OK, Thanks but then I am curious: Did you receive a datafile when you downloaded your project?

Please understand that in the B&S project (or at least my version) we "must" have an interface that has these 2 methods, and other methods. We also have a data access class, like you Urly Bird people do, where these "must" be implemented (which they gave us the name for). But when I get to this data access class and implement the 2 methods in question, I don't see any reason to put any statements in these 2 methods. However, I am still "implementing" the method, because the implementing data access class is not abstract. You can still implement a method from an interface without having any functional code in there, as long as the rules of overriding apply. At least it works in 1.5.

>>>BUT these methods have a very important description on their interface: optional.

If you are talkng about the comments with the "//" above the listed methods, I also have 3 or 4 lines of comments above these two methods in my instructions.html, but no where in the comments for these two methods is the word "must" used, whereas the word "must" is in fact used in comments for methods that will obviously contain coding in the implemented version.

>> I don't know, I really wouldn't take such chances. Mostly because implementing such methods are not hard at all.

But my fear is that I am taking chances by doing "more than what is truly expected" - something that both K&B and most of the ranchers here in the forum try to steer us away from..

So can I ask: If you look carefully at your instructions.html, can you really give me any good reason why you should have any real, functional code in the implemented versions of these methods? Because I haven't found anything yet in mine.

Thanks so much for your help with this.

[Eiji Seki]

Did you receive a datafile when you downloaded your project?

Yes, I did.

You can still implement a method from an interface without having any functional code in there, as long as the rules of overriding apply.

Of course it works. The issue is: even if it compiles, is it right? If the data class was something like DummyData in which you clearly state that nothing is done in the methods, that should be ok, since that's the reason that class exists. On the other hand, when the specification states that your class must implement an interface, I think anyone would expect the work to be properly implemented.

Well, you can always override the method's documentation and, in the javadoc of your concrete methods state that they just don't work.

(...) but no where in the comments for these two methods is the word "must" used (...)

Then we depend on the interpretation of what implements means.
For example, if I create a Data class that implements the interface but all it's method are empty and then I just use alternative methods, is it an correct implementation of the interface?

Well, you should at least justify your decision on choices.txt. But notice that it is quite strange to provide a half-implemented class. If you would want not to implement part of the methods, that should be separated in diffent classes. It does not look quite nice to have a class with a "not implemented, will be later". Why not provide an fully functional one?

[Eiji Seki]

Ow, just realized something to think about.

If you deliver more than it was required, you just get no extra points. If you do not deliver something that was required, you lose points. If you forget a must, you fail.

I am trying my best not to overdo, but when I am in doubt, just "better be safe than sorry".

(was the saying like that? :rolleyes

[Bob Nedwor]

Thanks, Eiji. But I still don't see any reason to expand these 2 methods beyond stubs. At the most, my implemented createRecord() method needs to return a long, so I will have 2 lines:
long tempLong = 0;
return tempLong;

This will suffice, because this method will never be called by the software with its current requirements. It is left over from a previous version of the exam. There is no requirement or must that I can see, where I will need to write a new record to the datafile. I will only be performing operations on the existing records. Sorry if you don't agree.

I hope someone else can speak up about this one way or the other. Andrew, any help here? or am I going down the path of throwing away $250.00 ?

[Andrew Monkhouse]

Hi Bob

[this method] is left over from a previous version of the exam.

Ummm, I'm willing to bet that you don't know that. You are just assuming that to make your own life easier. However it is true that some beta versions of the assignment required candidates to convert data from one format into another, which required use of the create() method.

Having said all that though, candidates have passed without implementing the create() or delete() methods.

I am not sure about your idea of returing zero when no record is created. This to me sounds like you are using a magic return value to indicate an error - something that exceptions are supposed to help us avoid. The java.lang.UnsupportedOperationException might work for you in this case.

Regards, Andrew

[Ronald Wouters]

Hi,

I have also this in my requirements:

Any methods that throw RecordNotFoundException should do so if a specified record does not exist or is marked as deleted in the database file.

To be able to test if a method correctly throws the RecordNotFoundException in case of deleted records you obviously need deleted records to test with.
My original downloaded database file did not contain any deleted records. So in order to fully test the throwing of the RecordNotFoundException I had no choice but to implement fully the delete method, just to be able to generate some test data.
A similar situation applies for the create method. The data in the provided database file (URLyBird) all had room available dates that were a lot older than 48 hours (yes the famous 48h rule). In order to generate test data to test my implementation of the 48 hour rule, I need some records with recent available date (today and yesterday). So again, to test this, I had to fully implement the create method, just to generate my own testdata.

Doesn't your assignment have any requirements that, in order to test them fully, would require you to fully implement the create and delete methods ?
Just my five cents again...

Regards, Ronald.
[ February 20, 2006: Message edited by: Ronald Wouters ]

[Bob Nedwor]

Thanks so much, Andrew. This is very helpful. Yes it makes perfect sense to me that candidates have passed without implementing the create() or delete() methods. The I will read the API Spec on the java.lang.UnsupportedOperationException, but by its mere wording, it seems perfect for what I need here. Thanks.

Thanks for your response, too, Ronald. I also will test my RecordNotFoundException method to ensure that it handles cases where a specified record does not exist, but that is it. There could never, ever be any records marked for deletion under my current B&S requiremements, because there are none in the provided data file and the user won't have any available mechanism in the gui to create this situation, directly or otherwise.

But if I did want RecordNotFoundException to handle records marked for deletion, I could simply test it by changing the first character of the data record in the data file from 00 to 0xFF manually. 0xFF is what our program is supposed to see as a deleted record indicator.

Either way, this whole SCJD thing is going to be a lot of work and a lot of learning, even just to get a basic passing score. So thanks so much for everyone's help with this. It is going to be a long haul, but worth it in the end.

By the way Andrew, your book is great. It came yesterday. Just by the few minutes I had to browse through it, I can tell that it is filled with tons of great info that I will be able to use well beyond my quest for the SCJD certificate.
[ February 20, 2006: Message edited by: Bob Nedwor ]

[Tomas Anderson]

candidates have passed without implementing the create() or delete() methods.

Good to know, but were points taken off? I would hate to lose a few crucial points just because I was too lazy to implement a method that would never be used.

The java.lang.UnsupportedOperationException might work for you in this case.

Again, a good idea, but the spec says to implement the interface, and the comment for the method deleteRecord() says "Deletes a record, making the ... storage available for reuse."

I feel that it would be bad programming to implement a method and purposely make it not do what it says it should. However, if the method is never going to be used, I see no point in doing extra coding to add unused functionality.

It seems that I have 3 choices about what to do with these unused methods, disregarding the 'return 0' idea which would get you mauled by any OO programmer who has to use your code.

Choices:

1) Add the functionality to the method AND add means of creating or deleting records to the GUI. This is probably not a good idea because the spec never says anything about the user having the power to create/delete records.

2) Add the functionality to the method but never call it. This would make it a little easier to add the power to create/delete to the GUI, but it seems like a lot of pointless work. However, you would be following the spirit of the interface.

3) Throw a RuntimeException (probably UnsupportedOperationException) whenever the method is called. This would fit into the simplicity emphasis of the assignment, but would not be honoring the *spirit* of the interface.


All in all, it seems quite a dilemma . I will try to avoid the problem until a definitive answer is found from Sun or another trustworthy source.

Sorry for the long post, I was weighing pros and cons for myself as I wrote down my options.
[ February 26, 2006: Message edited by: Tomas Anderson ]

[Bob Nedwor]

Yes, Thanks, Thomas. I plan to use the UnsupportedOperationException as I agreed above. Other than the throwing of this exception, there won't be any code in the implemented versions of these methods.