Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Requirements on the Data class instance(s)

 
Mattew Force
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 23
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Jason Moors
Ranch Hand
Posts: 188
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic