• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

NX: Can you pass if you extend DB ?

 
Ranch Hand
Posts: 197
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If you extend the supplied interface (DB) and have your Data class implement that, is that in any way penalised?

I know I will still comply with my spec, because I my data class will still be implementing DB. I'm just worried about Sun's dreaded testing software.

I was proposing to extend Suns interface and add some schema retrieval methods. And use objects of this type in my business layer.

Do the old hands know of any cases where this has been penalised?
 
Ranch Hand
Posts: 531
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by mike acre:
If you extend the supplied interface (DB) and have your Data class implement that, is that in any way penalised?

I know I will still comply with my spec, because I my data class will still be implementing DB. I'm just worried about Sun's dreaded testing software.

I was proposing to extend Suns interface and add some schema retrieval methods. And use objects of this type in my business layer.

Do the old hands know of any cases where this has been penalised?



If you use a DataCache class, it would serve as the perfect place for schema-retrieval methods. It is not permitted to extend the DB class. It must remain completely the same and named the same, because the specification says that even a minute deviation from the correct spelling may cause automatic failure. I think they check the spelling.
 
mike acre
Ranch Hand
Posts: 197
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Anton Golovin:


If you use a DataCache class, it would serve as the perfect place for schema-retrieval methods.



I want an interface type.


It is not permitted to extend the DB class. It must remain completely the same and named the same, because the specification says that even a minute deviation from the correct spelling may cause automatic failure. I think they check the spelling.



extending will not alter the DB interface will it!




has interface AA in any way altered A ?

Come on now Anton, back to SCJP
 
Anton Golovin
Ranch Hand
Posts: 531
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I got the same situation I would be delighted to extend the DB interface, but I think the software checks not only the type of the interface (an extension would be a DB, as well,) but it goes looks at the class name

As for exnteding the DB interface for use with a different class, I thought about that, too, but then what would I do with the lock methods? Instead I am making a DBClient interface.

If you somehow make it work, could you please tell me how? I am facing the same problem, and after having read in my assignment about the "spelling," I decided I would not risk it.
[ August 08, 2004: Message edited by: Anton Golovin ]
 
mike acre
Ranch Hand
Posts: 197
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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



so we have:

package suncertify.db;

public interface DB {

//etc as supplied
}

I propose:

package suncertify.db;

public interface DBX extends DB {

public Schema getSchema();
}

&

public class Data implements DBX {

or if we are scared of the testing software

public class Data implements DB, DBX {

As for exnteding the DB interface for use with a different class, I thought about that, too, but then what would I do with the lock methods? Instead I am making a DBClient interface.



I am only going to use my extended interface with Data.

spelling wise, Data is still called Data and it still implements DB

The spelling comment is quite general, I suspect the requirement with regards the interface and Data.java, is that the class files can be used by the software in that Data can be typed as DB - and mine will do that.
So their software doesn't need my extra methods defined in DBX, that doesn't matter.

but it goes looks at the class name



what class name?

you mean Data.java ? I still have that.
you mean interface name? DB I still have that.

I really don't see the problem. But I would like it confirming.

If I start another thread on this, please don't answer it unless you have the answer, I have a feeling that the 'old hands' don't take so much notice of threads with replies.
 
Anton Golovin
Ranch Hand
Posts: 531
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think I may have the answer. It is: one should not extend the DB interface. The instructions are quite clear on the DB interface. They say we must implement the DB interface as provided. I think it even says something like that. Sorry if I interjected into a thread that was meant for SCJD's

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

They write that wherever a "must" is seen, an absolute requirement is being described.

In my design I have:

DBCache class contains DBParser(read/write records) contains DBSchema(the schema.) DBSchema is build using DBSchemaBuilder. DBCache is the cached database.

If you happen to confirm this with someone else, please feel free to use this design: it abstracts away quite nicely all the "low-level" details from your Data class. In this design, it is the DBParser which needs the DBSchema, so your Data class never even has to know a schema exists. It only knows it is dealing with a DBCache object.

Again, sorry, I did not mean to subtract from your valuable time.
[ August 08, 2004: Message edited by: Anton Golovin ]
 
Ranch Hand
Posts: 697
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by mike acre:

I was proposing to extend Suns interface and add some schema retrieval methods. And use objects of this type in my business layer.



Not advisable. I think a couple of guys did, not sure though.
 
Satish Avadhanam
Ranch Hand
Posts: 697
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by mike acre:

I have a feeling that the 'old hands' don't take so much notice of threads with replies.





The more answers a thread have, it makes me think that there is something important...atleast to me :roll: and finally take a look at it

Anyway, Good Luck.
 
Ranch Hand
Posts: 1033
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Satish Avadhanam:


Not advisable. I think a couple of guys did, not sure though.



The approach I'm taking is to have the Data object use a DatbaseFile singleton to get at the actual data. This object has the schema retrieval methods. The Data object doesn't need them but they are needed by the business objects.
 
mike acre
Ranch Hand
Posts: 197
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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

They write that wherever a "must" is seen, an absolute requirement is being described.



If your Data class implements an interface that extends the supplied interface then YOU ARE COMPLYING WITH THE MUST REQUIREMENT!!!



In my design I have:

DBCache class contains DBParser(read/write records) contains DBSchema(the schema.) DBSchema is build using DBSchemaBuilder. DBCache is the cached database.

If you happen to confirm this with someone else, please feel free to use this design: it abstracts away quite nicely all the "low-level" details from your Data class. In this design, it is the DBParser which needs the DBSchema, so your Data class never even has to know a schema exists. It only knows it is dealing with a DBCache object.



Yes I have a similar schema object in more backend classes. I was just considering making it available through Data so my business tier only had to deal with one class. But now I shall let Schema slip round the side of Data. Just to be safe.


Again, sorry, I did not mean to subtract from your valuable time.



Sorry I was just getting a bit frustrated.

Still, a late session last night sees my app pretty much completed, now for the documentation, and the obligatory 'here's a design' posting.
 
Ranch Hand
Posts: 532
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
mike,

If you extend the supplied interface (DB) and have your Data class implement that, is that in any way penalised?


Personnaly, I think it is fine. Here is the reason.
The tester will check for the type, not the exact name.
for example:

public interface FirstInterface;
//privides method A()

public interface SecondInterface extends FirstInterface;
//inherits methods A()
//provides method B()
//now SecondInterface is a type of FirstInterface

public class Data implements SecondInterface
//implements methods A() and B()
//now Data class is a type of FirstInterface, and SecondInterface
//If you try the following lines of code, you should have no errors

FirstInterface firstObject = new Data();
SecondInterface secondObject = new Data();
Data dataObject = new Data();

The polymorphism works its magic here. I believe that is how they check to see if you follow the interface contract or not. If you don't feel comforible doing this. Make your data class implements two different interface- the interface given to you, and your own interface.
 
mike acre
Ranch Hand
Posts: 197
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Hanna Habashy:
mike,

Personnaly, I think it is fine. Here is the reason.
The tester will check for the type, not the exact name.

...

The polymorphism works its magic here. I believe that is how they check to see if you follow the interface contract or not. If you don't feel comforible doing this. Make your data class implements two different interface- the interface given to you, and your own interface.



I understand your reasoning perfectly, it is my own.

Just can't afford to risk it.

I can't implement 2 interfaces I need one object type that gives access to all methods. I could implement 3 interfaces

DB, SchemaKnower, and DBX that extends both of them, but then it gets real messy.

I think I'll make the right (safe) descision now.
 
Ranch Hand
Posts: 823
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi guys,

I think you're nuts to allow speculation about Sun's little automated test harness to influence your design choices. In the nicest possible way, of course!

I'm with Mike and Hanna in that I don't see a problem in extending the interface, given the wording of the assignment. I think we're all agreed that you'll be marked down if you change it, but that's kinda the point of interfaces. You can't change an interface in someone else's API, but you can extend it, and you can add other functionality to the implementing class. The only question is, does it make good design sense to do so?

However, I personally think that the strongest design would be Peter's, where there's no need to extend the DB interface. Having said that I'd be very surprised if you lost marks for either solution if you justify your choice. They're both perfectly valid options.

Just make sure you're confident that you've complied with all those MUSTs and leave Sun's little harness to its own devices. In the unlikely event that it does cause an automatic failure then you can simply appeal and, provided that you are right, Sun will be forced to fix their harness (which I'd be pretty confident is not broken, or it'd be all over the Ranch ) I don't think they're unreasonable people. I think most of the folks I've seen posting on here that they've failed will admit they failed for good reason, though they (obviously) didn't see it at the time.

From what I've seen of your postings you guys are not gonna fail unless you balls up your locking or your UI.

But, hey, what do I know?!

Jules
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic