Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

URLyBird: Question concerning "Data" class

 
Alex Duran
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm currently working on URLyBird (1.1.2) and the instructions contain the following statement:

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

[Definition of sunceritfy.db.DB interface follows...]

My question is - what is the scope of a "data access class"?

Minimally, it's clear that the class declaration for suncertify.db.Data must look like:



But does "Data Access Class" also mean that all aspects of the data access - including locking, file access, etc. must also be contained within the suncertify.db.Data class?

For example, let's say I wanted implement the "create" method in Data.java as follows:



where "doCreate" would be defined as an abstract method (thereby making suncertify.db.Data an abstract class) that would be overridden by subclasses that provide an implementation (e.g. a FixedFieldDataFile subclass would provide an implementation required for this assignment). In other words, I'd use a Template Method pattern.

Would the above approach (and similar) where implementation details have become the responsibility of classes other than suncertify.db.Data violate the requirement that mandates that suncertify.db.Data serve as the "Data Access Class"?

Thank you.
 
Alex Duran
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One correction...the line in the 2nd code example that reads:



Should have read:

 
Rudolph Jen
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
> But does "Data Access Class" also mean that all aspects of the data access - including locking, file access, etc. must also be contained within the suncertify.db.Data class?

IMHO it doesn't. The class "Data.java" must implement the provided interface, thats it. I did not put all following needed logic in that one class, or even in one big method. My Data.class delegates some issues to other classes, because I would like to get the cohesion on a good healthy level.

> Template Method pattern.

I am a fan of the Template Method myself, but I don't see the reason to use it here. Sorry Perhaps I am to dump to see it.

Best Regards,
R
 
Alex Duran
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rudolph,

Thank you for your reply.

The intent behind using Template Method is that if, for some reason the format of the data file were to change or the database were to change to something that did not use a file at all, those changes would be encapsulated elsewhere. The checks for pre-conditions, post-conditions, etc. could remain in the suncertify.db.Data class, however, since these will not change unless the interface of suncertify.db.DB changes.

What do you think? Maybe I have lost my mind
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic