aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Data access class Data must (directly) implement interface DB ? 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 "Data access class Data must (directly) implement interface DB ?" Watch "Data access class Data must (directly) implement interface DB ?" New topic
Author

Data access class Data must (directly) implement interface DB ?

Mihalydeak Szilard
Greenhorn

Joined: Jan 24, 2002
Posts: 7
Hi Everyone,

This topic has been discussed here earlier too, but now it's my turn to decide what to do about it. Please give your opinion and comments !

My SCJD assignment states:


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


As always, the provided interface is missing something, which now is support to handle metadata. The only plausible solution I see is to extend interface DB, and use that extended interface throughout the application.



Is this indirect implementation going to be against the requirements ? Sure I could write , but that doesn't make much sense other than meeting a (hidden) requirement to implement DB directly.

br. Szilard,

[Andrew: wrapped text]
[ August 23, 2004: Message edited by: Andrew Monkhouse ]
Marlene Miller
Ranch Hand

Joined: Mar 05, 2003
Posts: 1391
Hi Mihalydeak,

JLS 8.1.4 A class is said to implement all its superinterfaces.

It is possible that understanding the intent of the requirements is more than using a definition in the JLS.
[ August 23, 2004: Message edited by: Marlene Miller ]
Hanna Habashy
Ranch Hand

Joined: Aug 20, 2003
Posts: 532
Is this indirect implementation going to be against the requirements ? Sure I could write

No. I don't see anything wrong with that.


SCJD 1.4<br />SCJP 1.4<br />-----------------------------------<br />"With regard to excellence, it is not enough to know, but we must try to have and use it.<br />" Aristotle
Anton Golovin
Ranch Hand

Joined: Jul 02, 2004
Posts: 476
Sorry to dissent, but I do think the DB interface must be implemented directly unless Sun gives explicit permission. It is not a very convenient interface, to be sure - it lacks the methods to export schema parts, for instance, etc., and if I make the schema visible to my business-logic class, I am breaking every rule of design there is. So what's the solution? How do I use the interface DB in my business logic class to point to a Data object and still get the methods to handle metadata?

I am afraid there is no such way. The DB interface is a poorly designed one, and in the real world, I suppose the developer would go to the client and say, "I need an instantiate() method in the interface; I can't build an extensible system without this method."

So if you really want to write an extensible system where the metadata is downloaded to the client, so that you are not tied into only 7 data fields, write to Sun and get their permission. But short of that, I would not extend the DB interface. Come to think of it, I am going to write them. I really could use the instantiate method in my DB interface.

But if they don't give me permission, I will not extend DB. To hardcode field names into the application is the only way. I don't think it will cause point deductions for sticking to the language.


Anton Golovin (anton.golovin@gmail.com) SCJP, SCJD, SCBCD, SCWCD, OCEJWSD, SCEA/OCMJEA [JEE certs from Sun/Oracle]
mike acre
Ranch Hand

Joined: Sep 23, 2003
Posts: 197
Originally posted by Anton Golovin:
Sorry to dissent, but I do think the DB interface must be implemented directly



What is all this talk of direct/indirect?

It either implements or it does not, simple.

I too am guilty of my doubts and have posted accordingly. Who isn't when it comes to the risk of automatic failure.

However, my mind is clear now, you can do what you like if you can justify and satisfy the 'MUST's

My Data.java :


and if anyone has a better name than 'DBWithSchema' or my existing 'DBPlus' I want to hear it


SCJP 1.4, SCJD
Mihalydeak Szilard
Greenhorn

Joined: Jan 24, 2002
Posts: 7
and if anyone has a better name than 'DBWithSchema' or my existing 'DBPlus' I want to hear it


How about DB2 ?
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11423
    
  85

Hi everyone,

Originally posted by Anton Golovin:
So if you really want to write an extensible system where the metadata is downloaded to the client, so that you are not tied into only 7 data fields, write to Sun and get their permission. But short of that, I would not extend the DB interface. Come to think of it, I am going to write them. I really could use the instantiate method in my DB interface.


I will be surprised if you get an answer from Sun on this. But good luck, and please let everyone know if you do get an answer.

Originally posted by Mihalydeak Szilard:

How about DB2 ?




By the way, instead of extending the existing interface, have you considered creating your own totally seperate interface? Data class must implement the provided interface, but there is nothing to say that Data class can only implement one interface - it can implement as many as you like.

Regards, Andrew


The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
peter wooster
Ranch Hand

Joined: Jun 13, 2004
Posts: 1033
Originally posted by Andrew Monkhouse:
Hi everyone,





By the way, instead of extending the existing interface, have you considered creating your own totally seperate interface? Data class must implement the provided interface, but there is nothing to say that Data class can only implement one interface - it can implement as many as you like.

Regards, Andrew


I find that DBAccess interface to be very deficient in an number of ways. The more I work with it, the less I like it. It prevents the use of metadata and screws up exception handling. At present I'm assuming that the real requirement is to use this as it was provided, and to provide nothing more than this in the server. The results are quite ugly.

Maybe the solution resides in the Adapter pattern. The adapter could use the DBAccess interface and the low level database code to provide things like metadata, sessions, open, close, and reasonable exceptions. This is the interface that would be provided across the network. An alternative choice is to wrap the ugly interface in a Data Access Object.

Personally I intend to solve the problem using the provided interface first, and then see if there are better solutions.
Steven Hoodless
Ranch Hand

Joined: Mar 23, 2004
Posts: 64
By the way, instead of extending the existing interface, have you considered creating your own totally seperate interface? Data class must implement the provided interface, but there is nothing to say that Data class can only implement one interface - it can implement as many as you like.


Its always very easy to agree with Andrew. I think you could pass just by reading all his posts on this BB! My implementation had a DB interface and a DBExtra interface containing getSchema(). The Data class implemented them both. This fulfilled the requirements of the spec that Data must implement DB and my own personal requirements to include extra methods.

Somebody must have liked it.


Locking 80 / 80
NetServer 40 / 40
Data Store 40 / 40


Steven


SCJP, SCJD, SCWCD.
mike acre
Ranch Hand

Joined: Sep 23, 2003
Posts: 197
Hi Steven,

What I don't understand with this approach is how do you pass an abstract Data object that can use the DB interface methods and your getSchema method if you have two unconnected interfaces?

Data implements DB, DBExtra {}

but what do you type it as?
The only single object type that gives you access to all the methods you need is Data, and that defeats the point of interfaces.

I only use Data in one place, but that really needs decoupling with interfaces and access to all the methods
Surya Kumar
Ranch Hand

Joined: Aug 21, 2004
Posts: 52
The line in the instructions says that "Your data access class must be called "Data.java", must be in a package called "suncertify.db", and must implement the following interface",
So is it wrong to implement something more than that! Nothing has been said on this regard. Anyway how sun is tracking the MUSTs, are they using any kind of parsing tools! Which will fail the assignment if the line "public class Data implements DBAccess"!!!


Regards<br />Prem<br />SCJP, SCJD, SCWCD, SCBCD, SCEA, SCJDWS
mike acre
Ranch Hand

Joined: Sep 23, 2003
Posts: 197
Originally posted by Surya Kumar:
"Your data access class must be called "Data.java", must be in a package called "suncertify.db", and must implement the following interface",
So is it wrong to implement something more than that! Nothing has been said on this regard.


If it says you must do it then you must.

By implementing a sub-interface of DB then you comply with that must.

There is nothing to say you can not do this.

All the fuss is centered around those must requirements. You obviously must do more than just these are you wouldn't otherwise have a working system.

Does it say you must apply the 48hr rule? No, but following your logic, you shouldn't do that.
I know for a fact that people have scored poorly if they haven't or applied it badly.

There seems to be a fundamental problem with the English language here. Still, Sun are almost as bad... but then they are American.
 
jQuery in Action, 2nd edition
 
subject: Data access class Data must (directly) implement interface DB ?