It may be difficult to validate an individual property in its setter, if its correctness depends on another property (ex. : int minX and int maxX, where minX must be lower or equal than maxX : to set them both from 20,30 to 40,60 setMaxX() must be called before setMinX() or the call will fail. And inversely to reset them to their previous value...
![]()
Some properties are related to each other not for validation only, but because changing any of them may fire some action while all of them are used by the given action. Ex.: changing the IP Address or the listen port of your server could make it reset its listening process. But as both of those properties are used in the reset process, you probably won't initiate it automatically from any of the corresponding setters.
As there is no central place where to group your properties, you need at least to document your class to make clear, among your numerous instance variables, which are properties and which are not.
As properties are not seen as a whole, classes which use many of them may become hard to maintain.
Typically, such a GUI will need some in-memory container to store/retrieve properties.
As the GUI writer, as you have no way to validate the properties as a whole, you'll need to write validation routines yourself, probably at the GUI level, which is bad practice, but also supposes that you get some deep understanding of the related class.
The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Originally posted by Philippe Maquet:
Do you agree with my last arguments ? It may be as short as one word of 3 characters![]()
Originally posted by Philippe Maquet:
I hesitated before doing so, but after having compared both techniques (a simple container of public variables (1) vs a container of private variables along with getters/setters (2)), I concluded that solution (1) offered many advantages :
When I implement a new Settings class, I save the time of writing one getter/setter pair per property. As validation is better handled for the Settings object as a whole, the getters/setters would do nothing else than provide a public access to their corresponding private variable. Accessing properties through getters/setters would make the reflection part of the job harder. Just think of the fact that Settings supports array properties for all native types and String. For them, I would need special getters/setters ... In a Settings object, the convention used to identify properties is simple : there are all public fields, period. For instance, AbstractSettings stores a private prefix used to name properties. As it's private, it's automatically ignored. "public" acts as a "property-marker" and it's handy. If properties could be mixed with other instance variables at the same access level, I would need some other convention (based on the variale name ?), probably more complex to describe, remember, and follow. I found that using reflection on public fields to support automatic two-way conversion on all native types, Strings and arrays of them was ... complex enough ! Sure Mark would agree with it.
![]()
Originally posted by Philippe Maquet:
[Using a singleton] would be quite restrictive because classes which must support multiple instances with different settings values could not use that singleton or static properties container. I have a multi-tables db design : it makes sense that each Table instance gets its own DBSettings instance (maybe different cache settings but ... for sure a different file name).
Originally posted by Philippe Maquet:
No thread safety ? Right. But not less than the thread safety offered by HashMap or any array. It's up to the Settings user to make sure his code is thread-safe if he needs it.
Originally posted by Philippe Maquet:
Some properties are related to each other not for validation only, but because changing any of them may fire some action while all of them are used by the given action. Ex.: changing the IP Address or the listen port of your server could make it reset its listening process. But as both of those properties are used in the reset process, you probably won't initiate it automatically from any of the corresponding setters.
Originally posted by Andrew Monkhouse:
True, but this could be handled by having a setter with a "dontUpdateObservers" parameter.
Originally posted by Philippe Maquet:
OK. But it's still based on "special" setters (see my comments above).
Originally posted by Philippe Maquet:
you have less to document and you can do it in a simpler way
The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
"I'm not back." - Bill Harding, Twister
"I'm not back." - Bill Harding, Twister
I didn't think of any possible translation in french coming from you.
Mmh... Do you suggest that I should use the beans package ?
Isn't [the code] just simple (and complex
) enough for the scope of our assignment ?
The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Can you really tell me that we aren't dealing with suspicious baked goods? And then there is this tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
|