aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Using the unreferenced interface Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Using the unreferenced interface" Watch "Using the unreferenced interface" New topic
Author

Using the unreferenced interface

Daniel Dalton
Ranch Hand

Joined: Mar 20, 2005
Posts: 146
Hi all -

1) I've created my Data class, which implements the supplied DBMain interface.

2) I've got a remote interface called DBMainRemote which extends DBMain and Remote.

3) I've created a class called DataRemote which implements DBMainRemote by following the adapter pattern and delegating calls to an instance of Data.

My problem is as follows:

Ideally, rather than a reference to the concrete type "Data", I want DataRemote to hold a reference to a DBMain, so that I am programming to an interface rather than a concrete type.

I also want to implement Unreferenced. However, when the unreferenced() method gets called, I would need to unlock all records held by the client. While I could create such a method in the Data class, it would not be available if the reference is of the interface type, because it's not defined in DBMain (which I can't change).

Am I missing some neat trick, or should I just bite the bullet & document why I had to use a concrete type?
Darya Akbari
Ranch Hand

Joined: Aug 21, 2004
Posts: 1855
Hi Daniel,

as far as I can see, your data layer looks good. Concerning DataRemote and DBMain you answered your question yourself with your data layer design, didn't you? Wasn't it the same reason why you implemented DBMainRemote?

By the way you already do good and I recommend to keep it that way to document all your decisions in your choices document. I didn't and had immense trouble to recapitulate at the end of my project what the reason were for all my decisions. It all sum up and becomes a mess, believe me
.

Regards,
Darya


SCJP, SCJD, SCWCD, SCBCD
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11460
    
  94

Hi Daniel
I also want to implement Unreferenced. However, when the unreferenced() method gets called, I would need to unlock all records held by the client. While I could create such a method in the Data class, it would not be available if the reference is of the interface type, because it's not defined in DBMain (which I can't change).
Your "while" statement seems to imply that there is at least one alternative - having the class which implements Unreferenced (presumably DataRemote) track the locks created/released and unlock any outstanding locks.

Regards, Andrew


The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Uriy Kashtanoff
Greenhorn

Joined: Mar 30, 2005
Posts: 7
I had a similar issue. I wanted to have a shutdown() method in my Data class. This method would be called by either the server or the standalone app to "close" the database, so that all resources in use could be properly released. But the shutdown() method was definetely not defined by the DBAccess interface, and I wasn't brave enough to put it there. Here's how I resolved my problem. Since I had a DBAccessFactory which was responsible for creating concrete instances of DBAccess (via a static method createInstance() that returned DBAccess), I simply added another static method to this factory: shutdownInstance(DBAccess database). Inside of this method I used an instanceof to see if the provided DBAccess was indeed an instance of Data, and if it was, I casted it into Data and called the shutdown() method on it. The idea here is, since the DBAccessFactory knows what the concrete type is that it creates, there is nothing architecturaly wrong with casting to this concrete type (if the instanceof check passes) and calling the methods directly from concrete class.
Frans Janssen
Ranch Hand

Joined: Dec 29, 2004
Posts: 357
Hi Daniel,

How about introducing a new interface that extends both Unreferenced and DBMain and possibly adds the extra methods you need? Then you can still use a reference to an interface, but you don't need to change the DBMain interface.

But anyway: if you implement Unreferenced in your Data class, then the method to unlock all records could be a private method in the Data class (since it is only called from the unreferenced() method in the same class). So you wouldn't need to add this method to your interface and you would not need a interface-typed reference to your Data class, becaue this would suffuce. Or did I misinterpret your problem?

A question though: how did you make your DataRemote interface extend DBMain and Remote? In order for any class that implements DataRemote to be a remote object, all its methods must throw RemoteException. But a class that implements DBMain can not throw RemoteExceptions for the methods defined therein, sunce DBMain does not define these exceptions to be thrown. (Hint: must people solve this by using the Adapter pattern.)

Frans.
[ June 29, 2005: Message edited by: Frans Janssen ]

SCJP 1.4, SCJD
Daniel Dalton
Ranch Hand

Joined: Mar 20, 2005
Posts: 146
Thanks for all the replies - they're all very helpful!

Frans - you're right about that interface, I don't know what I was thinking when I posted that - I have a separate interface that has the same methods as DBMain, but adds RemoteException to the signatures, then I use the adapter pattern to go between the two.

Andrew - thanks for your feedback. I hope to avoid having to track locks in two places though. My Data class uses the services of a DataAccess class and a LockManager class because I believe that to be a better separation of concerns than having both database access and locking semantics in a single class. I plan to pass the request to release all locks held by a dead client through to the embedded LockManager for it to deal with (because that's its job!)

Uriy - I really like that idea! Having the factory class which created the object cast it back to it's concrete type to enable additional methods to be invoked feels perfectly valid to me, and more importantly I believe I can justify the choice.

Thanks again everybody!
 
jQuery in Action, 2nd edition
 
subject: Using the unreferenced interface