Monday February 23, 2004
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 )
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)
That's too many steps
- look in struts-config.xml for the class mapped to /SomerSault.do
- the <Action /> stanza forwards to something called somerSault.layout
- ok, next, look in tiles-defs.xml and one might find that somerSault.layout maps to /SomerSaultContainer.do
- alright, go back to the struts-config.xml to find /SomerSaultContainer.do
and see that it maps to the type com.example.SomerSaultContainer
- 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 )