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
