Jason Then wrote:Hi ranchers, this is my first post
Jason Then wrote:Regarding the requirement:
Your data access class must be called "Data.java"
Just wondering if Data.java can be an interface.
My reading of the statement in the instructions is that someone should be able to access the data by instantiating an instance of the Data class. There might be a chance of a loophole there where you could claim that your concrete class is a Data instance, however I don't know that I would risk it (especially since I think it is not needed - particularly with the workaround you have noted).
Jason Then wrote:Just wondering if Data.java can be an interface. This is my plan:
I suspect Sun to have a JUnittest to test Data.java with auto fail if the JUnit test does not succeed. So my advice: no interface, no abstract and a default constructor which will open the provided database from the current directory.
Sure the instruction don't demand all this but I see no advantage in making the assessors live difficult.
a default constructor which will open the provided database from the current directory
Hmmm I disagree with this... The spec says nothing about the need for a default constructor, and having such a constructor would be bad for testability and general bad coding practice as the constructor is doing too much work (see http://misko.hevery.com/code-reviewers-guide/).
Still not sure about the non-abstract Data class - in the link in my first post, Roel seems to have done it successfully??
Roel (that's me ) has thought about the idea of an abstract Data class, but that idea came into my mind a few days before I submitted. I didn't change my code, stuck to the code I already had, but added this idea in my choices.txt for enhancements in the future.
I don't know if they have a JUnit test to run, because I applied the singleton design pattern to my Data class which requires marking the default constructor private and so if the JUnit test tries to do new Data();, this test will fail.
Martin Krischik wrote:a default constructor which will open the provided database from the current directory
How do you know the database file name you have to open?
Roel De Nijs wrote:How do you know the database file name you have to open?
Same file name as provided:
instructions.html wrote:The original, unchanged database file that was supplied to you. Note that you must keep a copy of the original database file supplied to you, and this must be the file you submit. The marking process will expect the exact same data without any changes.
Of course since a default constructor is nor required there must be provision for a singleton design like yours. Mind you, where singletons not considered “evil” in Java?
I'd just like to give my opinion about the posts in this thread:
The instructions say that "Your data access class must be called "Data.java", must be in a package called "suncertify.db", and must implement the following interface". So it can't be an interface.
I'd say that a default constructor isn't required (that is, a public no-arg constructor). In case of a Singleton Data class, it won't have a default constructor.
The instructions just say that the Data class must implement the interface provided, so, in my opinion, as long as it implements this interface, there should be no problems making the Data class an abstract class. I think the idea is to keep compatibility with other systems that expect an implementation of the interface provided in the assignment, so if you provide a concrete class that extends this abstract class, it will work normally.
The instructions don't mention anything about the constructors to be provided in the Data class. However, in my opinion, forcing it to look for a file with the same name of the .db file provided in the current working directory is a bad idea. A more flexible project would be to let the user provided the name of the file when the application is started.