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. ... > > I think that lack of encapsulation (lots of direct access to request > and session via constants) in Struts is one of its weakest points, making it hard to test and hard to refactor, > Agreed. -T.
