HI Ranchers, On the same lines of thought,I was also a bit confused in declaring and using String variables for use in button text,menu text, frame title ,messages etc. I am making constants and using these constants for this purpose,but am confused as there is going to be only one instance of GUI building classes which make use of these variables on a perticular client,so isn't it be right to just have them as private variables instead of making them constants? Kindly comment VikasSood
Hi Vikas, Personally I prefer to have constants at the top of the class for this. It just makes it easier if you need to modify the names of the buttons later - they are all at the top of the file. You do not have to search for them. Regards, Andrew
Hi Andrew, In My implementation also i am having constants defined at the top the class for this pupose ex- private static final String BUTTON_NAME="Submit"; But what i was asking was should i just make the above variable private instead of making it a constant? Kindly comment VikasSood
Hi Vakas, Why are you creating one variable for the button label? Are you using that variable at many places? If so, better declare it as private static final constants. Compiler does some optimizations on such constants. I prefer to use like this: (J)Button submitBut; submitBut = new (J)Button("Submit"); But never ever declare constants in an interface. It is very bad desing, and one should avoid doing doing that. instance variable will be created for each instance, where as class constant will be one for all instances. Regards, Ganapathy.
I too would probably use a private static final variable. The private might be changed to something more public if other classes need access to the value. It's true that if the field is private, other classes won't be able to change the value (well, unless they use reflection), and so "final" may not be necessary. However (a) we may wish to protect against future changes to this class by other coders (or ourselves, after we've forgotten details of how it works); (b) saying "final" makes the field simpler to understand for everyone; especially in a multi-threaded environment we may need to think about what happens if various fields change, and seeing "final" we know we don't have to worry about it; (c) the compiler can better optimize accesses to the field in some cases if it's final. One possible reason not to use constants for things like button labels is if you've got an internationalized application. You may wish to offer the user to change the language the GUI presents in; in this case, things like button labels will be read (and re-read and changed) from a resource bundle. So this would be a good reason not to make the button labels constant. It's not necessary for the developer cert assignment, I'm sure - but may be worth considering for similar projects in the real world. [SG]: But never ever declare constants in an interface. It is very bad desing, and one should avoid doing doing that. Ummm, I disagree with the "never ever" part. If the constants are intended to be part of the API, which users of an implementing class should know about and have access to, then constants in interfaces may be appropriate. E.g. consider java.util.Calendar - pretend it was an interface rather than abstract class. Here it's entirely appropriate to define a constant like Calendar.JANUARY, so that users of the class can say something like cal.set(Calanedar.MONTH, Calendar.JANUARY). I'm not going to say Calendar is a good example of API design :roll: , but the use of constants per se is not a problem. When are constants in an interface a bad thing? It's when they're put there not because the users of the interface need the constants, but because the implementors want them. E.g. take a look at ObjectInputStream. What are all those fields inherited from ObjectStreamConstants? They're not fields that anyone using an ObjectInputStream needs to know about. They're just fields that the people who wroteObjectInputStream (and ObjectOutputStream[/i]) wanted to talk about, and they wanted to be able to write things like if (val == PROTOCOL_VERSION_1) rather than if (val == ObjectStreamConstants.PROTOCOL_VERSION_1) so they chose to implement ObjectStreamConstants to save themselves some typing. This is a poor reason to put constants in an interface - it brings those constants into the public API of your class, when they should be a private implementation detail. So, I agree constants in an interface are often a bad thing - but not always. Joshua Bloch complains specifically about interfaces that are designed just to export constants - but he never says that all constants in interfaces are bad. The thing to remember is, they become part of the public API of all implementing classes. If there's a reason to expect they should be part of the public API (as for Calendar) then go for it. [ May 24, 2003: Message edited by: Jim Yingst ]
Friends, In many cases you will find ResourceBundle to be the right thing to use. ResourceBundle is not for internationalization only and I use it in my implementation. But to a certain extent it is a matter of preference. Regards, +Seid
Joined: Mar 26, 2003
Hi Jim Yingst, I know your standard in java etc... It is difficult for me to cross your comments many times. I forgot to mention the reference what you mentioned. Based on Effective Java Programming Language Guide by Bloch, I mentioned the comment. java.util.Calendar is strictly an abstract class, and not an interface. Declaring only constants in an interface is bad design, it was my intention to tell. More over, we are not writing APIs to declare public constants. If we do write things like that, we should design interface very carefully. GURU, please correct me, if I am wrong. My comment was purely based on "Joshua Bloch's" book only. Hey man, BTW in my db file, I too found spaces instad of null string(ASCII 32 instead of ASCII 0). Sorry to merntion about it here. Thanks n Regards, Ganapathy.