• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

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

 
Ranch Hand
Posts: 266
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Ranch Hand
Posts: 619
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ulrich Heeger
Ranch Hand
Posts: 266
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 619
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 266
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 619
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 266
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 266
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 266
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 619
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 266
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 have a knack for fixing things like this ... um ... sorry ... here is a consilitory tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic