What's That Noise?! [Ian Kallen's Weblog]

All | LAMP | Music | Java | Ruby | The Agilist | Musings | Commute | Ball
« Previous page | Main

20040223 Monday February 23, 2004

Constants Abuse Hard-coding string and numeric values into application logic is often problem-plagued. I tcan lead to duplication, which leads to maintenance nightmares, which can lead to increased substance abuse, drinking, crack cocain... it's a treacherous road. Don't go there.

It's a pretty common (and usually, good) practice amongst java programmers to organize all of the little magic values that application logic depends on into a class that defines public constants. However, this can lead to another problem: constants bloat. Cases where the developer needs to define a constant that is only accessed by one component (let's just call a single class and its instances "one component" for the time being) but stores it in a shared centralized constants class is another form of substance abuse. It's constants abuse.

I would really prefer to see constants with a limited scope of applicability confined to that scope. For instance, if it's only used by one class -- define it in that class, not the shared centralized beast. If it's only used by a cluster of classes that work on a particular area, perhaps there's already a bean that they all know about; the constant may be better suited for that bean than a class shared system-wide.

Confine the scope of your constants definitions to where they are useful and save yourself and your colleagues maintenance headaches down the road. ( Feb 23 2004, 10:55:14 AM PST ) Permalink
Comments [1]

20040221 Saturday February 21, 2004

Tiles Definition Files: anti-pattern? Struts tiles definition files allow the developer to refer to components to include symbolically. Besides the struts-config.xml, this is an additional configuration point. Ostensibly, the extra layer of indirection eases maintenance and re-use. However, I've found it to be flawed:
It increases the maintenance burden by requiring mappings in two different xml files and these mappings are easily abused
For instance, suppose updating the UI logic on the SomerSault widget is required. The developer may have to traverse two different mapping types (struts class mapping and tiles component mapping)
  1. look in struts-config.xml for the class mapped to /SomerSault.do
  2. the <Action /> stanza forwards to something called somerSault.layout
  3. ok, next, look in tiles-defs.xml and one might find that somerSault.layout maps to /SomerSaultContainer.do
  4. alright, go back to the struts-config.xml to find /SomerSaultContainer.do and see that it maps to the type com.example.SomerSaultContainer
That's too many steps
There's no compile-time validation
The developer might make all of these changes and be please that everything compiles, including the JSP components (using the jasperC ant task). However, at runtime if the names don't match up, it's difficult to debug where the problem is.
It would be preferable to define any symbolic names for components as constants in a compiled class (say TileDefinitionConstants), this would make the names uniformly available to the Action classes and JSPs. Exposing the symbols to the JSPs would require writing a little tag library but that's a trivial feat. ( Feb 21 2004, 10:22:50 AM PST ) Permalink