File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes NX:Adding to given interface Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "NX:Adding to given interface" Watch "NX:Adding to given interface" New topic
Author

NX:Adding to given interface

Don Resnik
Greenhorn

Joined: Dec 06, 2003
Posts: 18
I just read an old post about not being able to change the provided interface. I added an getColumnNames() method to the interface so I could access the column names programatically from the Data class, instead of hard coding them. The docs say that the database must remain intact due to some legacy issues, so you argue that it is ok to hard-code it, but I thought it would be better to have a method to get them from. Any thoughts?? The old post made me nervous because I am close to sumbitting this project and I would hate to fail for something like this. I also have this addition to the interface and the reasons for it well-documented in my choices.txt
Thanks in advance for the comments.
Don
Bill Robertson
Ranch Hand

Joined: Mar 21, 2003
Posts: 234
What do your instructions say. I thought adding to the interface was
a big No No, but now after reading my directions it doesn't appear
that way.
Why not just create a new interface
that extends the interface provided by sun, add your method, have
data implement this interface and your done.
Jay Bromley
Ranch Hand

Joined: Aug 09, 2003
Posts: 48
Hello,
The "can I add to the interface" question is one I've thought about a good bit. My instructions (B&S) say
Your data access class must be called "Data.java", must be in a package called "suncertify.db", and must implement the following interface:

I've read this to mean as long as I provide the given interface I'm good. I assume there's some sort of automated testing of the core database functionality and so the interface methods must be present exactly as indicated. This does not preclude adding some methods, I think. In particular I've got a method to provide information about field lengths so the GUI and configure itself well. I believe others have done something similar and passed. I'm still not 100% on this, though.
Regards,
Jay
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
This does not preclude adding some methods, I think.
Maybe not, but this is a risk. The instructions say you MUST implement their interface. I would say to be safe, keep that interface exactly as they have provided it. But you can certainly add other methods to the Data.java class. And as Bill said, you can extend the provided interface, so that you add new method declarations to a new, separate interface. But I think it's a risky idea to make changes directly to the interface Sun has specified. Even if some people may have passed while doing so (and I don't know if any have) it's an inherently risky move, IMO.


"I'm not back." - Bill Harding, Twister
Don Resnik
Greenhorn

Joined: Dec 06, 2003
Posts: 18
Thanks for the responses so far.
I do not want to add any additional methods to Data.java, becuase I am using DBAccess for both local and remote connections (to do this I had to add 'throws RemoteException' to all methods in the DBAccess...is that as bad as adding a method?) Anyway, methods added directly to Data.java (local implementation) or DatabaseRMIImpl (remote implementation) would not be accessable from DBAccess. I also do not think I can extend the interface because the docs say that Data.java must implement DBAccess.java.
I am leaning toward hard-coding the columns
public static final String[] DB_COLUMNS = {"....","..."...}
I think I can easily justify that given the supplied docs. Does anyone have another solution?
Thanks,
Don
joe black
Ranch Hand

Joined: Dec 03, 2003
Posts: 103
I have a separate class which only contains constants such
as number of fields, field lengths, record length, etc... I didn't
want to spend the time writing methods to extract this data if it's
given in the spec. And if the schema were to change, all you need
to do is go into that class and change some of the values, since I
isolated them.
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
I had to add 'throws RemoteException' to all methods in the DBAccess... is that as bad as adding a method?
IMO it's worse. This is a bad idea. You're not just adding to the interface; you're changing it.
methods added directly to Data.java (local implementation) or DatabaseRMIImpl (remote implementation) would not be accessable from DBAccess.
Well that's why why create a new interface which extends DBAccess. If the client knows it's using a NewImprovedDBAccess (WithGreenPwerCrystals) then it can call these cool new methods you're creating. You're still implementing DBAccess, but you're also implementing a better interface which actually does what you want.
I also do not think I can extend the interface because the docs say that Data.java must implement DBAccess.java.
If you implement NewImprovedDBAccess then you are implementing DBAccess. If you want to make this really obvious (on the assumption that Sun amy be using really, really stupid automated testing for this requirement) the you can even declare the class like this:

This should be completely unnecessary, but doing this may conceivably save you from a round of arguments with Sun in the event that you have the bad luck to be assigned a clueless grader. I have no info on how likely this possibility is; probably Sun's empplyees are far too smart for this level of ineptitude. But if you want to be paranoid, it's easy to protect yourself in this particular case by directly declaring that you implement both interfaces.
[ December 24, 2003: Message edited by: Jim Yingst ]
Jay Bromley
Ranch Hand

Joined: Aug 09, 2003
Posts: 48
Jim,
You are of course, correct You precisely said what I wanted to say. The DB interface is cut and paste directly from my assignment (of course I added the appropriate doc comments) and I actually added one method to the Data class, which is the implementer of the DB interface.
Regards,
Jay
james airey
Ranch Hand

Joined: Dec 15, 2003
Posts: 41
I would vote very strongly against throwing new exceptions on a defined interface. That may well break Sun's test program, which would be automatic failure.
Philippe Maquet
Bartender

Joined: Jun 02, 2003
Posts: 1872
"public class DBAccess implements DBAccess, NewImprovedDBAccess " : very nice shot, Jim !
I'd like to add just this about *why* the provided DBAccess shouldn't be changed *at all* (though it's OK to extend it). An interface is a *contract* that *our* Data class must fulfil. But who knows whether other possibly *existing* classes have the same contract ? If you change DBAccess in any way, you take the risk to break other people's existing code. And that's very bad . Your collegues could even hate you for doing that.
Best,
Phil.
[ December 24, 2003: Message edited by: Philippe Maquet ]
Don Resnik
Greenhorn

Joined: Dec 06, 2003
Posts: 18
Thank you all very much for the comments and suggestions. I will definately not change the interface.
Don
Don Resnik
Greenhorn

Joined: Dec 06, 2003
Posts: 18
Well, I thought this made sense to me but after thinking about it, I have some questions:
If DBAccess has a method readRecord(long r) that does not throw any exceptions, can NewImprovedDBAccess extend DBAccess and have a method readRecord(long r) that throws RemoteException? Is this how I get the option of using the 'throws RemoteException' without altering DBAccess?
Also, I understand that you are not supposed to change interfaces because they are contracts. However, I added 'throws RemoteException' to my DBAccess methods, but I did not add 'throws RemoteException' to my methods in the Data class (I did add it to methods in my DataRMI class, which also implements DBAccess). How can adding 'throws xxxException' break existing code if the exsiting code does not have to use the 'throws xxxException', like my Data class?
Thanks for your responses,
Don
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
[Phil]: "public class DBAccess implements DBAccess, NewImprovedDBAccess " : very nice shot, Jim !
Thank you. However I just noted that I wrote DBAccess where I meant Data. It's now fixed in the original post.
[Don]: If DBAccess has a method readRecord(long r) that does not throw any exceptions, can NewImprovedDBAccess extend DBAccess and have a method readRecord(long r) that throws RemoteException? Is this how I get the option of using the 'throws RemoteException' without altering DBAccess?
No. For this, you'll need another interface which looks like DBAccess (or NewImprovedDBAccess) but does not actually extend it - because you need to be able to throw RemoteException from each method, and you can't do that and also implement the original interface. The new interface must extend Remote in order to allow you to access it with RMI.
[Don]: How can adding 'throws xxxException' break existing code if the exsiting code does not have to use the 'throws xxxException', like my Data class?
But there is existing code which throws it, if you're using RMI. The rmic command generates stub classes which will throw RemoteException if there's any networking problem. And you'll need to have code on the client which can catch this exception and deal with it if it's thrown.
[ December 24, 2003: Message edited by: Jim Yingst ]
Don Resnik
Greenhorn

Joined: Dec 06, 2003
Posts: 18
Ok, I think I get it now. The interface I am implementing now is essentially the NewImprovedDBAccess. It has all the methods of DBAccess, but it extends Remote and all the methods throw RemoteException. All I have to do now is have Data also implement the original DBAccess as well and I will meet the requirements of the project. Both of these interfaces will be independent of each other. I am not planning on adding any additional functionality to NewImprovedDBAccess, although I could.
Thanks again for all your help.
Don
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
Ummm... well I was thinking of two different new interfaces. NewImprovedDBAccess is the one that extends DBAccess for new methods you may need, and RemoteDBAccess is the Remote version of this. If you have decided not to add any functionality, then you can omit NewImprovedDBAccess, and just have DBAccess (as defined by Sun) and RemoteDBAccess.
Note that If you do decide to have a NewImprovedDBAccess, it should probably have a better name than that; I just made it up as a joke. Something like EnhancedDBAccess might be more professional-sounding.
Philippe Maquet
Bartender

Joined: Jun 02, 2003
Posts: 1872
Jim:
[Phil]: "public class DBAccess implements DBAccess, NewImprovedDBAccess " : very nice shot, Jim !
Thank you. However I just noted that I wrote DBAccess where I meant Data. It's now fixed in the original post.

Oops ! I even didn't notice it. My comment applied on implementing DBAccess *and* the improved interface which extends it.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: NX:Adding to given interface
 
Similar Threads
9th,10th and 11th question from chapter 10 of kathy Sierra.
GUI
Need help understanding how to synchronize methods correctly
Help with Model View Control concept
What's up with the revival of old posts?