Extending the Oracle supplied Interface

[Glen Iris]

Hi Guys and Gals, I hope you're having a nice weekend

I am implementing the threading pat of B&S at the moment and I came across an interesting post by the excellent and helpful rancher Roel De Nijs. The quote is from Robertos tests for locking thread. The quote, if I read it correctly seems to suggest that it is valid to create your own interface which extends the Oracle provided interface, modify the methods you feel need modifying and then implement your newly written Interface and have no more dealings with the Oracle interface. Am I losing it or is that permitted?

Roel said:

.... And I would take it 1 step further: update/delete/unlock should NEVER throw a RNFE, because you have to lock a record and after successfully locking it, another thread can't do anything with it (so certainly not deleting), otherwise there would be something wrong with your locking mechanism. That's why I created an own interface (extending Sun's interface of course) and I redefined these 3 methods without the throws RNFE clause (and of course I added an explanation in my choices.txt about it).

Kind regards,
Roel

[Roel De Nijs]

Glen Iris wrote:an interesting post by the excellent and helpful rancher Roel De Nijs

It's always nice to get a compliment. That's what keeps us running (and of course all the free beer bartenders get in the saloon )

Glen Iris wrote:Am I losing it or is that permitted?

It all depends on what you want to do

1. It's completely legal to extend the given interface and have your own interface with some extra methods (e.g. an extra find-method which returns record numbers & records). If your Data class implements your own interface, it will also implement the given interface and you are not violating any must requirement

2. You can also redefine 1 or more existing methods (the ones you get from the given interface), but you still have to make sure that you keep valid overrides (otherwise your program will not compile). E.g. the update-method in my interface has exactly the same signature as in the given interface except for the throws-clause. Because a record must be successfully locked before it can be updated, a RNFE can only be thrown by the lock-method, so for the update-method that's never going to happen, so I removed this throws-clause (and this decision was of course well-documented in my choices.txt)

3. you still have to provide an implementation for every method in the given interface. So you can't add a new create-method for example (with a signature you prefer more than the given one) and implement your create2-method and throw an UnsupportedOperationException from the original create-method. That's risky business and could result in (automatic) failure.

Good luck!

[Glen Iris]

Roel De Nijs wrote:

Glen Iris wrote:an interesting post by the excellent and helpful rancher Roel De Nijs

It's always nice to get a compliment. That's what keeps us running (and of course all the free beer bartenders get in the saloon )

Glen Iris wrote:Am I losing it or is that permitted?

It all depends on what you want to do

1. It's completely legal to extend the given interface and have your own interface with some extra methods (e.g. an extra find-method which returns record numbers & records). If your Data class implements your own interface, it will also implement the given interface and you are not violating any must requirement

2. You can also redefine 1 or more existing methods (the ones you get from the given interface), but you still have to make sure that you keep valid overrides (otherwise your program will not compile). E.g. the update-method in my interface has exactly the same signature as in the given interface except for the throws-clause. Because a record must be successfully locked before it can be updated, a RNFE can only be thrown by the lock-method, so for the update-method that's never going to happen, so I removed this throws-clause (and this decision was of course well-documented in my choices.txt)

3. you still have to provide an implementation for every method in the given interface. So you can't add a new create-method for example (with a signature you prefer more than the given one) and implement your create2-method and throw an UnsupportedOperationException from the original create-method. That's risky business and could result in (automatic) failure.

Good luck!

Thanks yet again Roel. It was almost too good to be true until I saw point 3! I was planning on creating a new update method and pass it a Contractor object instead of a String array.

[Roel De Nijs]

Glen Iris wrote:I was planning on creating a new update method and pass it a Contractor object instead of a String array.

You could try that, but I'm afraid chances on failure will be big. But if you want to take a risk, just go for it (and let us know how it went).

From a design perspective I would definitely not create such a method, because it makes your interface and Data class dependent on Contractors, so no code reuse at all. My interface & Data class can be (almost) completely reused for handling similar data files containing customer info, hotel info and so on.

[Robin van Riel]

The reason mentioned by Roel for creating an extended interface is of course a perfectly valid one, but please don't be fooled (like I was at first) by the notion that you need to extend it to add missing functionality.
I thought the original interface wouldn't suffice since I wanted records to be returned instead of indices, I wanted a book method to be in there, etc.
While in fact the original interface contained all the basic methods I needed for the Bodgitt & Scarper assignment.

I ended up making the search ("find" returning records) and book methods part of the service interface, instead of the data interface.
These methods couldn't care less where methods like "read" and "find" get their data from (RMI, Sockets, DB File, etc).

[Roel De Nijs]

Sorry for that misunderstanding. Not trying to fool you

Like you said it's perfectly fine to just implement the given interface. It was just something I did because with my given interface I felt there was something missing. Creating your own interface is not a must requirement at all.

And search/book methods should indeed be in a seperate service (that's what I did too) and these methods use the methods from the given interface (and/or your custom interface).

[Robin van Riel]

Hi Roel,

No worries, I fooled myself long before I read your post ;).