Constants are not always "owned" or strongly related to any particular class -- in those scenarios, you definitely want to move to a common one (like we did with Globals in Struts 1.1). It can also lead to cleaner imports if you only have to import one class to get the constant declarations.Hi guys, Thanks for your replies. Can you give examples of usage patterns that would dictate that it is ok to move constants away from their owning classes? I also think the type safe enum pattern is a great idea, but I do not see this being used a lot in practice (though I think it should be). Justin
A related hack I've seen used on occasion is to define the global constants in an interface, rather than a class. Then, your logic class can say "implements Globals" and reference the constant names directly (without having to prefix them with the class name, as you do to reference static constants in other classes).
Typesafe enums make sense when the underlying data really is an enumeration of values that represents the total set of valid inputs to a method. This is true, for example, when the constants are the integer subscripts into a fixed size array, and you want to avoid the possibility of IndexOutOfBound exceptions. (On the other hand, it makes iterating through the values harder.) I don't find them of much use when the constants are Strings, because in most of those scenarios the number of legal values is usually not limited -- the constants are just well-known identifiers rather than being the only valid values. For example, it wouldn't make sense to define a typesafe enum class for request attribute keys.
Craig
-----Original Message----- From: John Cavacas [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 29, 2003 7:43 PM To: Struts Users Mailing List Subject: Re: Design decision for Globals class
I agree with David. Constants should be defined where they are relevant. But once you start using them in other places, then refactor them out to a common Constants class. The Type Safe Enum pattern might also be something worth looking at depending on your use of such constants.
John
At 04:15 PM 29/10/2003 -0800, you wrote:
In general, constants should be defined in the class they're relevant in. The Struts Globals constants used to be defined in Action; however, they're used in many places other than Action so it made sense to move them to the new Globals class.
David
--- Justin Mahoney <[EMAIL PROTECTED]> wrote:
Hi, A colleague of mine and I are discussing the relative merits of having something like a Globals class. I argue that it removes the constants from their proper association with a parent/owning class, ignoring the concept of object orientation and losing a self-documenting aspect regarding its relationship in the class hierarchy. By making the constants global they inherently lose scope, type association, and encapsulation. Another drawback is that you now have to flip between two JavaDocs pages when looking at a class and its constants. My friend argues that it's easier to reference a Globals class when programming since all constant Strings useful in the architecture are collected within, and therefore this is reason enough to have a Globals class (works great obviously with IDE auto-complete). If anyone has the time or inclination to comment, what were the design decisions that led to the Struts Globals class? Thanks, Justin
__________________________________ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
