Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Can we extend interface?

 
Eric Kim
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Provide interface is a sample interface which does not have Remote tag in it, also none of the methods throws RemoteException. If I choose to use RMI, then I have to create RMI interface to extend from java.rmi.Remote and also throws RemoteException. Should I modify provided interface definition to fit my needs, or create a seperate interface?
Thanks!
 
Satish Avadhanam
Ranch Hand
Posts: 697
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Eric
Originally posted by Eric Kim:
Provide interface is a sample interface which does not have Remote tag in it, also none of the methods throws RemoteException. If I choose to use RMI, then I have to create RMI interface to extend from java.rmi.Remote and also throws RemoteException. Should I modify provided interface definition to fit my needs, or create a seperate interface?
Thanks!

It is not advisable to change or add anything to the provided interface. Creating a new interface is a good approach.
 
Eric Kim
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So will this work:
1) Keep Sun interface DB.java intact.
2) Implement Data.java which implements DB.java which uses RandomAccessFile as a member variable and implement all methods defined in DB.java (Obviously).
3) Clone DB.java to DBRemote.java, but extends DBRemote from java.rmi.Remote, also throw one more exception: RemoteException for each method.
4) Create DBImpl which implements DBRemote interface, inside it uses Data as a membervariable and delegates all calls to Data instance.
5) Create DBFactory which either construct a Data instance for local mode or DBRemote instance for remoting mode.
The rest of work should be very straight-forward.
Would someone please check whether this design works for Sun requirement?
 
Satish Avadhanam
Ranch Hand
Posts: 697
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Eric Kim:
So will this work:
1) Keep Sun interface DB.java intact.

Yes.

2) Implement Data.java which implements DB.java which uses RandomAccessFile as a member variable and implement all methods defined in DB.java (Obviously).

Yes.

3) Clone DB.java to DBRemote.java, but extends DBRemote from java.rmi.Remote, also throw one more exception: RemoteException for each method.

Yes. Or you can implement only required methods that you want to expose to the client in DBRemote interface instead of implementing all the methods as given in DB.

4) Create DBImpl which implements DBRemote interface, inside it uses Data as a membervariable and delegates all calls to Data instance.

Yes almost. Instead of using Data directly, you may also want to think of introducing some security or you may want to use any design patterns like Adapter, Bridge here to mask Data class from directly accessed from Remote class.

5) Create DBFactory which either construct a Data instance for local mode or DBRemote instance for remoting mode.

Yes.

The rest of work should be very straight-forward.

Well, almost. I think you are still in the initial design only. As the project unwraps and you start doing we need to make many decisions. As always, many knowledgeable ranchers who already passed (am still working on it) will be here to help us.

Would someone please check whether this design works for Sun requirement?

Good Luck.
 
George Marinkovich
Ranch Hand
Posts: 619
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Eric,
Originally posted by Eric Kim:
So will this work:
1) Keep Sun interface DB.java intact.
2) Implement Data.java which implements DB.java which uses RandomAccessFile as a member variable and implement all methods defined in DB.java (Obviously).
3) Clone DB.java to DBRemote.java, but extends DBRemote from java.rmi.Remote, also throw one more exception: RemoteException for each method.
4) Create DBImpl which implements DBRemote interface, inside it uses Data as a membervariable and delegates all calls to Data instance.
5) Create DBFactory which either construct a Data instance for local mode or DBRemote instance for remoting mode.
The rest of work should be very straight-forward.
Would someone please check whether this design works for Sun requirement?

I think this design is consistent with the Sun requirements. Whether "the rest of the work should be very straight-forward" is true or not, you're off to a good start. One of the major design problems you need to solve in this assignment is how to create a common interface that can be used to support local and remote database access. The complications involved in doing this will become clearer as your implementation progresses. But for every complication there is a solution (often multiple solutions from which you have to choose).
 
Eric Kim
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi George,
Thanks for reply. I just realized that wedo need a common interface, because I think the DBFactory will look like this:
public DBCommonInterface getDatabase( String[] args ) throws DBException
{
if args.length == 0
return new Data("db-1x1.db");
else
if args means it is server then
return (DBCommonInterface)Naming.looup(uri);
}
My current design only has Data class implements DB interface, DBImpl implements DBRemote which wraps around Data, so this is not going to work:
new Data will return Data or DB type, while Naming.lookup( uri ) will return DBImpl or DBRemote type.
I do need a DBCommonInterface so both Data and DBImpl implement that interface to make this factory object work.
But how that common interface should look like? Can someone shed some light on this?
Thanks!
 
George Marinkovich
Ranch Hand
Posts: 619
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Eric,
Originally posted by Eric Kim:
But how that common interface should look like? Can someone shed some light on this?

The common interface is discussed in this thread:
Topic: A complicated database design...
WARNING: beware of my fallacious "implicitly implements" argument which is withdrawn at the end of the thread; other than that the ideas are mostly sound.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic