On your way in you may have missed that we have a JavaRanch Naming Policy for displayed (screen) names. Your displayed name must consist of a first name (or an initial), a space, and a family name (in that order) and not be obviously fictitious. Since yours "PaulSeldon07", does not conform with it, please take a moment to change it, which you can do right here.

Posters with nonconforming displayed names will be locked out of JavaRanch after a few posts using those names.

In the interface given by SUN, only seven methods are declared. Can I insert my own method in this interface, such as

public List<ContractorClass> readAll() throws IOException;

If you can let me know asap, it would be really appreciated.

No, I wouldn't do. And it is not necessary. I think if you find it necessary, then there is something wrong with your design. I see what you are driving at, and what I've done is create another class that handles the abstraction (with a ContractorClass, etc.) and that calls the low level Data that implements the Sun interface as given. Then you make use of your class with higher level of abstraction from the client/server side.

I have extended DB interface and added two methods to new interface. Now Data class will implement new interface with additional methods. You can add more methods to new interface (which extends DB) as per your requirement.

I know many people on this forum has done this and my assignment doesn't say you have to implement DB directly in Data class.

I know many people on this forum has done this and my assignment doesn't say you have to implement DB directly in Data class.[/QB]

You can't if it says this:

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

package suncertify.db; public interface DB"

SCJA, SCJP (1.4), SCJD

Ken Boyd
Ranch Hand

Joined: Dec 10, 2003
Posts: 329

posted Feb 01, 2007 12:53:00

0

Originally posted by Brian Kelly:

You can't if it says this:

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

package suncertify.db; public interface DB"

Yes my assignment says the same...

My new interface call ReadXY.java which extends DB.java also in same package. In that case why I can't use it? I mean Data.java is implementing DB.java methods plus some other methods from ReadXY.java interface as well...

thank you

Ken Boyd
Ranch Hand

Joined: Dec 10, 2003
Posts: 329

posted Feb 01, 2007 13:04:00

0

You can also refer to following thread where people pass with above solution..

It does say " Portions of your submission will be analyzed by software; where a specific spelling or structure is required, even a slight deviation could result in automatic failure."

Perhaps it's okay, but I'm not taking any risks with any "must"...

Ken Boyd
Ranch Hand

Joined: Dec 10, 2003
Posts: 329

posted Feb 01, 2007 13:38:00

0

Originally posted by Brian Kelly:

It does say " Portions of your submission will be analyzed by software; where a specific spelling or structure is required, even a slight deviation could result in automatic failure."

Perhaps it's okay, but I'm not taking any risks with any "must"...

Yeah that is jar file name and directory structure and also file names like Data etc.. not the design part if I am not wrong.. [ February 01, 2007: Message edited by: Ken Boyd ]

Ken Boyd
Ranch Hand

Joined: Dec 10, 2003
Posts: 329

posted Feb 01, 2007 13:41:00

0

Please someone who pass recently or our guru Andrew can confirm. It will be of great help.

Thank you

Vincent Li
Greenhorn

Joined: Jan 12, 2007
Posts: 22

posted Feb 01, 2007 17:29:00

0

I don't understand why this issue keep coming up over and over. Why do people keep wanting to change the interface when ultimately, your Data.java will have to implement all these String[] methods anyway?

IMHO, may be many people's impression is that your client will call these methods directly somehow and it doesn't look nice. You'd want to call something like "List<Record> search(Criteria)" versus "long[] findRecord(String[])". That's fine. The two are really separate things. It seems like a straightforward OO desing to have one call the other. Your client sees the high level one and you access the database with the Sun provided one.

Personally, I opt for 3/3a as a better OO design in that it never exposes any of the Data/DBAccess stuff to the rest of the world (encapsulation). It seems pretty obvious to me. But that's just my opinion.

I know many people on this forum has done this and my assignment doesn't say you have to implement DB directly in Data class.[/QB]

[Brian Kelly]:

You can't if it says this:

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

package suncertify.db; public interface DB"

If Data implements MyDB and MyDB extends DB, then Data implements DB. Simple. If you want to assume that Sun's testers might not grasp this point (or can't write a decent automated test for this) then you can make it more obvious by writing

Such a redundant declaration is perfectly legal, if a bit silly. But if it alleviates some concerns, what the heck... [ February 02, 2007: Message edited by: Jim Yingst ]

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

Ken Boyd
Ranch Hand

Joined: Dec 10, 2003
Posts: 329

posted Feb 02, 2007 10:05:00

0

Originally posted by Jim Yingst:[Ken Boyd]:

I know many people on this forum has done this and my assignment doesn't say you have to implement DB directly in Data class.

[Brian Kelly]:

You can't if it says this:

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

package suncertify.db; public interface DB"

If Data implements MyDB and MyDB extends DB, then Data implements DB. Simple. If you want to assume that Sun's testers might not grasp this point (or can't write a decent automated test for this) then you can make it more obvious by writing

Such a redundant declaration is perfectly legal, if a bit silly. But if it alleviates some concerns, what the heck...

[ February 02, 2007: Message edited by: Jim Yingst ][/QB]

Thanks Jim. It will be big surprise if SUN writes (they can no question about that) scripts to check Data extends DB but play safe with $400 investment