wood burning stoves 2.0*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Requirements on the Data class instance(s) 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 "Requirements on the Data class instance(s)" Watch "Requirements on the Data class instance(s)" New topic
Author

Requirements on the Data class instance(s)

Mattew Force
Greenhorn

Joined: May 03, 2007
Posts: 16
Hi guys,

I'm wondering if the examiners/assessors require that the Data class can be instansiated separately so they can test it that way.

My code doesn't allow this. I have another class, called Database, that extends the Data class and reads the metadata, schema information, etc. of the data file before it is possible to read/write/delete records through it. It is not possible to read/write/delete records only by instansiating the Data class because it needs information about data offset, record length and deleted records from the other class.

I don't want the Data class to hold schema information and cached records because that should exist at a higher level which is accessible by the business layer.

Do you think my solution will pass?
S J Martin
Greenhorn

Joined: Jul 31, 2007
Posts: 23
Hmmm, I'd be dubious as we suspect that they might use it for automated testing - especially for multi-threaded behaviour.

I, too, have a schema class (and several classes and interfaces), however, they are all access by the data class (which is thus simply a delegate). This seems sensible has the data class has quite high level functions in it (for a data access layer).

HTH


Never attribute to malice that which is easily explained by incompetence.<br />SCJP (1.5)
Jason Moors
Ranch Hand

Joined: Dec 04, 2001
Posts: 188
I think you need to ensure the methods defined by the DBMain interface work as described, otherwise you are breaking the contract of the interface.

However that does mean you can't add additional methods in your Database class, i.e. the offset/schema can be stored in you data class to enable the read/update methods, but only exposed to your business layer by your Database interface.

Regards
Jason
Mattew Force
Greenhorn

Joined: May 03, 2007
Posts: 16

I, too, have a schema class (and several classes and interfaces), however, they are all access by the data class (which is thus simply a delegate). This seems sensible has the data class has quite high level functions in it (for a data access layer).
[/QB]



Won't you break the interface if your Data class acts as a delegate? If you have additional public methods, shouldn't they be defined in the interface as well?
Mattew Force
Greenhorn

Joined: May 03, 2007
Posts: 16
Originally posted by Jason Moors:
I think you need to ensure the methods defined by the DBMain interface work as described, otherwise you are breaking the contract of the interface.

However that does mean you can't add additional methods in your Database class, i.e. the offset/schema can be stored in you data class to enable the read/update methods, but only exposed to your business layer by your Database interface.


Thank you for your reply, Jason. Your response helped me realize that the schema should probably be stored in the data class, otherwise I will have problems following the contract of the interface.

Regards,

Mattew
Mattew Force
Greenhorn

Joined: May 03, 2007
Posts: 16
I also realized that the schema should be instantiated in my database class and then passed to the data class constructor as a parameter. By doing it this way I won't need to add a getSchema method in the data class which would break the interface.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Requirements on the Data class instance(s)
 
Similar Threads
B&S Data.java
B&S DB Design
Could anyone help on seek() please?
No shutdown hook?
Unit testing class that deals with file I/O