This week's book giveaways are in the Java EE and JavaScript forums.
We're giving away four copies each of The Java EE 7 Tutorial Volume 1 or Volume 2(winners choice) and jQuery UI in Action and have the authors on-line!
See this thread and this one for details.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes NX: Can I justify my implementation at the database access level Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "NX: Can I justify my implementation at the database access level" Watch "NX: Can I justify my implementation at the database access level" New topic
Author

NX: Can I justify my implementation at the database access level

Ulrich Heeger
Ranch Hand

Joined: Jun 06, 2003
Posts: 266
Hi everyone,
since I finally arrived at the documentation phase, I have to justify all my design choices and now I doubt some of them.
For example, as an auxililiary class for my Data - Class I have created a so-called "DataHelper"-Class.
Within this class I have some methods like:

Because in my Data-Class I have only a static RandomAccessFile whose reference can be passed as argument to above methods and all DataHelper's methods accessing the database are static & synchronized, thus I guarantee that concurrent access to the database-file will be handled without data corruption.
That all works very fine, now I have just one point the caller of these methods has to be aware of: In DataHelper I have two setter-methods:

These methods set the property recOffSet - determining the offset where the data of the records start within the database file - and the property recLength - the length(number of bytes) of a record.
Without these properties DataHelper's methods won't be able to correctly access the database-file.
Thus, before calling the database accessing methods, these properties should be set.
In my implementation, starting the application, a singleton instance of MetaData-Class is created which reads the Schema description section and sets the above properties of DataHelper.
But for reason of encapsulation, I have to describe these special conditions within the JavaDoc comments at DataHelper Class.
Now my question: Do you think I can justify a Class design, where it's necessary to first set explicitly properties before calling other methods?
I'm thinking about to throw an IllegalStateException within the getRecOffSet() and getRecLength()-method of my DataHelper-Class in case the properties haven't been set explicitly before.
Is this exaggerated caution?
I hope I haven't confused you with all these information, but I would be very glad and thankful if you could help me.
Thanks in advance & greetings
Ulrich
[ March 03, 2004: Message edited by: Ulrich Heeger ]
George Marinkovich
Ranch Hand

Joined: Apr 15, 2003
Posts: 619
Hi Ulrich,
Originally posted by Ulrich Heeger:

Now my question: Do you think I can justify a Class design, where it's necessary to first set explicitly properties before calling other methods?
I'm thinking about to throw an IllegalStateException within the getRecOffSet() and getRecLength()-method of my DataHelper-Class in case the properties haven't been set explicitly before.
Is this exaggerated caution?

Not at all, it seems like you would want to pass in the recOffset and recLength as parameters to the DataHelper class constructor. Then you know you will never have an instance of DataHelper for which the recOffset and recLength members are uninitialized.


Regards, George
SCJP, SCJD, SCWCD, SCBCD
Ulrich Heeger
Ranch Hand

Joined: Jun 06, 2003
Posts: 266
Hi George,
thank you very much for your help.
Not at all, it seems like you would want to pass in the recOffset and recLength as parameters to the DataHelper class constructor. Then you know you will never have an instance of DataHelper for which the recOffset and recLength members are uninitialized.

Good point. But I don't want to create any instance of DataHelper-Class, because this class consists exclusively of static methods. But I just thought to pass a further parameter to the DataHelper methods, like:

, to enable the methods to extract from meta (a reference to the Singleton instance of MetaData) the necessary informations.
Sounds reasonnable?
Greetings
Ulrich
George Marinkovich
Ranch Hand

Joined: Apr 15, 2003
Posts: 619
Ulrich,
Having a class that has no state but only provides static methods is fine. If that's the case you should have a private default constructor to ensure that no one can instantiate the class. However, if the class has state (for instance, recOffset and recLength) then it should have a constructor that takes the parameters that determine the state, and the methods that depend on that state should be instance methods rather than class methods. It seems to me that your class does have state, so that state should be represented by instance variables, a constructor, and instance methods.
An alternative is to keep the static methods and use parameters to pass the state into each method. Then the class wouldn't need instance variables, or a constructor, or instance methods. But this seems like a workaround to allow you to have a stateless class, when it would be more natural in an object-oriented sense to recognize that the class has state. If you find that you're passing state into each of the static methods of a class, you might instead want to store the state in instance variables, provide a constructor that assigns the state, and provide instance methods that reference the assigned state. This seems to me to be more object-oriented, and results in a simpler parameter list for each method since you're not having to pass state into the method every time you call the method. What is the advantage to having the methods be static?
[ March 03, 2004: Message edited by: George Marinkovich ]
Ulrich Heeger
Ranch Hand

Joined: Jun 06, 2003
Posts: 266
Hi George,
thanks a lot for your informative comments.

What is the advantage to having the methods be static?

The reason why I wanted to have only static methods is to ensure the synchronization. Within my Data-Class I use synchronized blocks on the static HashMap "lockedRecords" for the locking procedure.
So I wanted to use synchronized methods for the physical access to the database file (for reasons of elegance, diversity or what the hell knows why ) Thus, if my methods within DataHelper are static and synchronized, I ensure the threadsafe access for multiple Data-instances.
But your comments give me the idea to change my implementation in the way that - like you suggest - I will have a constructor taking the parameters that determine the state. Thus each Data-instance will have its own DataHelper instance; for ensuring the thread safety I will synchronize on the object raf which is a static variable in Data Class, storing a RandomAccessFile instance. I mean something like:

Do you think it's ok to synchronize on a passed argument, I think yes, because the synchronization concerns the object itself and not the reference variable. Am I right?
Thanks & Greetings
Ulrich
[ March 03, 2004: Message edited by: Ulrich Heeger ]
George Marinkovich
Ranch Hand

Joined: Apr 15, 2003
Posts: 619
Hi Ulrich,
Originally posted by Ulrich Heeger:
Do you think it's ok to synchronize on a passed argument, I think yes, because the synchronization concerns the object itself and not the reference variable. Am I right?

I agree with you about it being OK to synchronize on an method parameter for the same reason you gave -- it's an object.
Would it be possible for the DataHelper class to be a singleton? If so, would it be possible to move the raf to the DataHelper class? In that way it may be possible to have a static instance of the DataHelper class in the Data class and then database operations could synchronize on this static instance. Then you would have a single database file, a single raf to access the file, a single class to support accessing the raf (DataHelper). Each Data instance would synchronize its database operations on the static DataHelper instance in Data. This would essentially abstract the database file entirely out of the Data class and it would reside solely in the domain of the DataHelper.
Ulrich Heeger
Ranch Hand

Joined: Jun 06, 2003
Posts: 266
Hi George,
I haven't seen the wood for the trees
I can, of course pass raf also as argument to the constructor of DataHelper.
Greetings
Ulrich
Ulrich Heeger
Ranch Hand

Joined: Jun 06, 2003
Posts: 266
Hi George,
I have seen you have answered me just in the moment where I add my second reply. Thank you. I will answer tomorrow.
Good sleep
Ulrich
Ulrich Heeger
Ranch Hand

Joined: Jun 06, 2003
Posts: 266
Hi George,
Would it be possible for the DataHelper class to be a singleton? If so, would it be possible to move the raf to the DataHelper class? In that way it may be possible to have a static instance of the DataHelper class in the Data class and then database operations could synchronize on this static instance. Then you would have a single database file, a single raf to access the file, a single class to support accessing the raf (DataHelper). Each Data instance would synchronize its database operations on the static DataHelper instance in Data. This would essentially abstract the database file entirely out of the Data class and it would reside solely in the domain of the DataHelper.

Sounds . But if I have a static instance of the DataHelper Class within my Data-Class, I don't need to make my DataHelper Class explicitly corresponding to the Singleton Pattern, am I right?
Greetings & thanks
Ulrich
George Marinkovich
Ranch Hand

Joined: Apr 15, 2003
Posts: 619
Ulrich,
Originally posted by Ulrich Heeger:
Sounds . But if I have a static instance of the DataHelper Class within my Data-Class, I don't need to make my DataHelper Class explicitly corresponding to the Singleton Pattern, am I right?

Yes. Originally I said it should implement the Singleton design pattern, but upon further reflection it seems to me there's no need to unnecessarily limit the architecture to a single database file. If it's instantiated as a static object in the Data class that should be sufficient.
Ulrich Heeger
Ranch Hand

Joined: Jun 06, 2003
Posts: 266
Hi George,
I think you convinced me, I will leave my concept of static methods and adapt your idea of a static instance of DataHelper.
Thank you very much for your help and your patience
Greetings
Ulrich
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: NX: Can I justify my implementation at the database access level