This week's book giveaway is in the OCMJEA forum.
We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line!
See this thread for details.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Can Data.java be an interface? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCM Java EE 6 Enterprise Architect Exam Guide this week in the OCMJEA forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Can Data.java be an interface?" Watch "Can Data.java be an interface?" New topic
Author

Can Data.java be an interface?

Jason Then
Greenhorn

Joined: Jun 26, 2010
Posts: 17
Hi ranchers, this is my first post

Regarding the requirement:
Your data access class must be called "Data.java"


Just wondering if Data.java can be an interface. This is my plan:


I have trawled the forums looking for a decent answer to this. The closest I could find was this: http://www.coderanch.com/t/444967/java-developer-SCJD/certification/abstract-Data-class
It still doesn't definitively answer my question about whether Data can be an interface or not.

One reason why I think it should be an interface is because then it could easily be substituted for different implementations - instead of CachedData we could have SqlData or FlatFileData etc.

Technically, I feel that the data access class is still Data.java, but I just wanted to double check so as to not risk auto-fail.

Obviously if this is an issue, the workaround could be this:


However, I feel that the naming of Data is more generic and lends itself better to being an Interface rather than a concrete implementation.

Cheers,
Jason
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11437
    
  87

Jason Then wrote:Hi ranchers, this is my first post

Welcome!

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).


The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Martin Krischik
Greenhorn

Joined: Apr 29, 2010
Posts: 23

Jason Then wrote:Just wondering if Data.java can be an interface. This is my plan:


I suspect Sun to have a JUnit test 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.


SCJP, SCJD, OCPJBCD
Jason Then
Greenhorn

Joined: Jun 26, 2010
Posts: 17
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??
Martin Krischik
Greenhorn

Joined: Apr 29, 2010
Posts: 23



Interesting - especially I like the “Suspicious names” - don't use the one of those names and half his reviews are spoiled.

Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5233
    
  12

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?


SCJA, SCJP (1.4 | 5.0 | 6.0), SCJD
http://www.javaroe.be/
Jason Then
Greenhorn

Joined: Jun 26, 2010
Posts: 17
So Roel, would you or wouldn't you recommend making Data abstract. Do you think I could get away with it by documenting it in choices.txt?
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5233
    
  12

I would simply not take such a risk.
Martin Krischik
Greenhorn

Joined: Apr 29, 2010
Posts: 23

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?

Roberto Perillo
Bartender

Joined: Dec 28, 2007
Posts: 2265
    
    3

Howdy, y'all.

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.


  • Cheers, Bob "John Lennon" Perillo
    SCJP, SCWCD, SCJD, SCBCD - Daileon: A Tool for Enabling Domain Annotations
     
    It is sorta covered in the JavaRanch Style Guide.
     
    subject: Can Data.java be an interface?