At 9:40 AM -0400 8/31/05, Ted Husted wrote:
On 8/31/05, Joe Germuska <[EMAIL PROTECTED]> wrote:
My design preference for things like this (as is playing out in
Struts 1.3) is to define a single scoped bean which can contain any
references like this, so as to sharply minimize the need for
constants like this. If you do that, then you're down to a single
constant to use to retrieve that bean, and then everything else can
be retrieved via strongly typed accessors, which plays nice with IDE
autocompletion and tools like that.
Yes, we do this at work, but we load the defaults via dependency injection.
So instead of defining the defaults in code, we define them in the XML
configuration.
A related technique is to use this object as the base or parent for like
objects. You can define a set of defaults in the parent and let everyone
else inherit the settings. (Or override them in the children, if need be.)
So, instead of asking someone else for a constant, the object can refer to
one of its own properties. This technique would be clumsy in conventional
code, but it's quite slick when dependency injection is in play.
Actually, what you're describing I think is not at all what I'm
describing, or only tangentially so. It does sound interesting,
though.
Is your Defaults object still basically just a reference to String
keys which should be used to store things in maps? Or is it an
object which has typesafe property getters/setters but internally
encapsulates the mapping of those types/roles to map keys?
A simple Defaults object still doesn't deal with the fact that many
things may come to depend on the key values, and many of those things
are hard to refactor, like view templates (JSP, Velocity,
what-have-you).
Joe
--
Joe Germuska
[EMAIL PROTECTED]
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
