You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Justin Mahoney <JM...@ditech.com> on 2003/10/30 00:10:17 UTC
Design decision for Globals class
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
Re: Design decision for Globals class
Posted by John Cavacas <jo...@johncavacas.com>.
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 <JM...@ditech.com> 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: struts-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: struts-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Design decision for Globals class
Posted by David Graham <gr...@yahoo.com>.
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 <JM...@ditech.com> 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: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
RE: Design decision for Globals class
Posted by Yansheng Lin <ya...@isogis.com>.
You mean something like GlobalConstants.java class. Isn't that a standard
practise nowadays? Where else would you store something like "ROOT_PACKAGE"?
With meaningful variable names, GlobalConstants can save you a lot of time
trying to matching things up, especially if you uses session.setAttributes() a
lot:).
-----Original Message-----
From: Justin Mahoney [mailto:JMahoney@ditech.com]
Sent: October 29, 2003 4:10 PM
To: 'Struts Users Mailing List'
Subject: Design decision for Globals class
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
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org