Create and Delete

[Keith Jones]

Hi All,

Would I be right in saying that although we are required to implement the two interface methods 'create' and 'delete' that we are not actually required to use these methods via our interface?

[Rudolph Jen]

Hi there.

For the "User Interface" I can find following in the specification:

"The user interface for this assignment MUST satisfy the following criteria:
- ...Swing..
- ..SEARCH..
- ..present search result..
- BOOK -> that means an UPDATE-operation"

Therefor there I can not find any reason why we should implement CREATE and DELETE.

I think, the best idea would be to throw an "java.lang.UnsupportedOperationException" That is an RuntimeExcpetion, so that you do not have to declare this in method definition.

Any other thoughts?

[Keith Jones]

I guess that is fair enough. I have already written the code for these methods so I might just leave them in. For those who have done this we could mention in our choices.txt files that we have written them so that if we add this functionality in the future into our GUI then the methods are already written. But definately your idea sounds better.

On another topic of the methods in the interface we have to implement which of those methods use lock, unlock and islocked?

[Rudolph Jen]

But remember:

"Correctness
... You will not receive extra credit points for work beyond the requirements of the specification"

But if your extra code does not work as requested..I know it is not called..but I feel more safe, just let it blank (throw Exception)

[Mark Smyth]

Originally posted by Rudolph Jen:
Hi there.

For the "User Interface" I can find following in the specification:

"The user interface for this assignment MUST satisfy the following criteria:
- ...Swing..
- ..SEARCH..
- ..present search result..
- BOOK -> that means an UPDATE-operation"

Therefor there I can not find any reason why we should implement CREATE and DELETE.

I think, the best idea would be to throw an "java.lang.UnsupportedOperationException" That is an RuntimeExcpetion, so that you do not have to declare this in method definition.

Any other thoughts?

Originally posted by Rudolph Jen:
But remember:

"Correctness
... You will not receive extra credit points for work beyond the requirements of the specification"

But if your extra code does not work as requested..I know it is not called..but I feel more safe, just let it blank (throw Exception)

Just because the create and delete methods are not not required in the current user interface does not mean that they should not be implemented in the Data class.

The create and delete metods are required by the specification:

Your data access class must be called "Data.java", must be in a package called "suncertify.db", and must implement the following interface:
....

Nowhere does it say that you should only implement the methods of the Data class that will be used by the user interface.

I think that if you just throw an UnsupportedOperationException you risk losing alot of points from your Data implementationscore at best or automatic failure at worst. Besides it not really much more work if you already have the update method implemented.

Regards,
Mark.

[Keith Jones]

On another topic of the methods in the interface we have to implement which of those methods use lock, unlock and islocked?

Does anyone have an answer to this question though?

[Keith Jones]

However Mark,

I think Rudolph has a point. If we were to be literal about it throwing an unreorted exception does equate ti IMPLEMENTING the method. On th other hand it does mean we are not implementing it according to the specification. It's something that ca be argued either way and I'm sure if you explain yourself in the choices file you should be ok. But don't take that as a guarantee from me anyone. What do I know?

[Mark Smyth]

Originally posted by Keith Jones:
However Mark,

I think Rudolph has a point. If we were to be literal about it throwing an unreorted exception does equate ti IMPLEMENTING the method. On th other hand it does mean we are not implementing it according to the specification. It's something that ca be argued either way and I'm sure if you explain yourself in the choices file you should be ok. But don't take that as a guarantee from me anyone. What do I know?

True, but you could also leave all the method bodies in Data blank and have implemented the interface correctly, and I don't think the score would be very high in that instance. Just because something compiles correctly doesn't mean its a good implementation. Its completely up to yourself how you design and document your project, but the UnsupportedOperationException route just seems to be a very risky strategy for the sake of a extra two hours work.

Mark.

[Rudolph Jen]

Is somebody reading this, who has already successfully passed the SCJD and did not implement these methods (and got points on this part)?

After all I am with you: I don't know it either!! I am just guessing

[Mark Smyth]

Originally posted by Rudolph Jen:
Is somebody reading this, who has already successfully passed the SCJD and did not implement these methods (and got points on this part)?

After all I am with you: I don't know it either!! I am just guessing

I've read a fair few posts in this forum over the last year or so and I have never heard of anyone who has tried it before. On another point there is a good chance that the methods in your Data class will be tested automatically by some kind of test harness during the marking proceedure. After all there must be a good reason that they ask you to return the orignal data file in the submission jar.

Mark.

[Muhammad Shafique]

On another topic of the methods in the interface we have to implement which of those methods use lock, unlock and islocked?

We should use these methods before updating the record. Somebody else may be updating the same record which we want to update. Same thing is true in case of delete record.

I am agree with Mark that we should implement all methods in DBMain because future enhancement is a plus in SCJD assignment. UnsupportedOperationException could be meant that method does not exist from its whole entirety or we have the method signature but no implementation yet.
I have implemented all methods of DBMain at DB layer (in fact some more to make remote processing more efficient). I am using MVC at client side and controller is using just select and update. But if there is a need to add other methods, you just need to put a call in controller and may have to do some minor GUI modifications. I am not saying that this is the perfect way. This is just what I think is proper. There may be some better way including the option UnsupportedOperationException.


Regards,
Shafique

[Ken Boyd]

Originally posted by Keith Jones:
Hi All,

Would I be right in saying that although we are required to implement the two interface methods 'create' and 'delete' that we are not actually required to use these methods via our interface?

I am doing as you said implement both methods and test using Add and Delete button in UI but remove when submit. This way we are safe like implement DB in Data.java and also support feature enhancement.

[Jair Elton]

I not certain, but the first step of evaluation are software based test, probably the automatic test software, test all methods on the data access layer, and a Exception probably not expected and cause an automatic failure, or not?

[Ken Boyd]

yeah they can do all kind of automated test on all methods but we can test using Add and Delete button for our testing and later on remove from UI since it is not mention in spec (mention in choice.txt that as future enhancement you can add those buttons)

[Maciej Miklas]

in my opinion gui does not require delete/insert, but the interface requires it - we should implement the interface - so we need delete and insert on the interface level, not exposed to gui.

Regards,
Maciek