Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

NX:Static or not static

 
Bill Robertson
Ranch Hand
Posts: 234
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If your Data class is a singleton, is there really any point in making
its lock structure static (or anything else for that matter).
 
Bharat Ruparel
Ranch Hand
Posts: 493
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Bill,
I don't see any point in making the lock structure static if you are using the Data class as a Singleton. Since you are limiting it to only ONE instance, it is at the class level anyway.
By the way, why are you making your Data class a singleton? Using multiple instances of the Data class, i.e., one each for a client gives you better concurrency and throughput. Just a thought.
Regards.
Bharat
 
Michael Fitzmaurice
Ranch Hand
Posts: 168
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Bill
IMO, the choice as to whether or not you make something static should not hinge upon whether or not you intend the enclosing class to be used as a Singleton - just use the same heuristics you would normally use in determining what should be static and what shouldn't. For example, even with a Singleton, you still need a reference to an instance of the class in order to call a non-static method - ask yourself whether each method you are providing should be available for use without a reference to an instance.
Normal rules about dependence on internal state should apply equally to Singletons as to regular classes (i.e. if a method does not rely on any internal state specific to an individual instance to do its job, it may be a good candidate for a static modifier - if it does, then don't make it static, even if you see the enclosing class as a Singleton).
One of the advantageous side-effects of designing this way is that you can rest assured that changing the design from a Singleton to a normal class at a later date will not leave you with any oversights in your API as a result.
You may decide at some point that your data class should not be a Singleton after all - if you have neglected to design appropriate parts of it to act at class level (because you were confident that there would only ever be one instance, so why bother?), you will find yourself with more changes to make.
[ September 17, 2003: Message edited by: Michael Fitzmaurice ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic