« Struts Validator:... | Main | New Oracle JDBC... »
20030227 Thursday February 27, 2003

How do you manage your Constants? I'm sure most of you Java Developers have a methodology for handling your "constant" values. I've seen a couple of different techniques, and I'd like to see what everyone else is doing. Currently, I use a Constants.java file that has a bunch of public final static String lines in it. I got this technique from the struts-example app when I first started working with Struts. I recently came across (can't remember where) a technique where the Constants.java file was an Interface and it was simply implemented. How are you handling this in your apps?

Secondly - do you ever use these Constants in your JSPs, or do you just use the actual values? I use the actual values - less typing. Posted in Java at Feb 27 2003, 09:40:01 AM MST 5 Comments

Comments:

I use the same Constants.java file. I do reference values in this class from within JSPs though, so I can reference session attributes and request parameters that are keyed on names defined in the Constants.java file. eg. A key for a "user role" object would be defined in Constants.java to be: public static final String ROLE_KEY = "role"; And I reference that role by its key in the JSP like: <bean:define id="role" name="<%= Constants.ROLE_KEY %>" scope="session" type="com.simsol.util.Role"/> More typing, but makes it easier incase the actualy constant's value changes (say from "role" to "user_role") for some reason. I won't have to go back into each JSP and change it.

Posted by dsuspense on February 27, 2003 at 12:22 PM MST #

Oops: forgot the code I use the same Constants.java file. I do reference values in this class from within JSPs though, so I can reference session attributes and request parameters that are keyed on names defined in the Constants.java file. eg. A key for a "user role" object would be defined in Constants.java to be: public static final String ROLE_KEY = "role"; And I reference that role by its key in the JSP like: 
<bean:define id="role" name="<%= Constants.ROLE_KEY %>" scope="session" type="com.simsol.util.Role"/>
More typing, but makes it easier incase the actualy constant's value changes (say from "role" to "user_role") for some reason. I won't have to go back into each JSP and change it.

Posted by dsuspense on February 27, 2003 at 12:23 PM MST #

Last try: <bean:define id="role" name="<%= Constants.ROLE_KEY %>" scope="session" type="com.simsol.util.Role"/>

Posted by dsuspense on February 27, 2003 at 12:25 PM MST #

You're currently following the best approach. Implementing a Constants interface is bad practice because: 1) It's not readily apparent where CONSTANT_KEY comes from, especially if the implementing class also extends a hierarchy and/or implements more interfaces than Constants. Knowing where your objects are defined at a glance is key to maintainable code. 2) Interfaces should expose an aspect of a class's behavior to clients. Even marker (empty) interfaces, which are often the tool of the devil, say something about what you can do with them, i.e. Serializable. With that said, though, it's not a bad idea to keep all those constants in a Constants interface so long as your class doesn't actually implement it... it should continue to reference them as Constants.FOO. Since interfaces can't have behaviors, keeping Constants that way enforces its intention to hold just data, not methods. As to JSPs, they should always use the constants themselves. Constants are useless if you can't change them once and affect all of their consumers.

Posted by Ryan Scharer on February 27, 2003 at 12:30 PM MST #

An interesting pattern for dealing with constants is discussed in "Effective Java" by Joshua Block. In it, he describes the typesafe enum pattern and the many benefits that arise from it. Were you to take your series of String constants and use this pattern, it would look similar to this: public class Constant { private final String const; private Constant(String const) { this.const = const; } public String toString() { return const; } // Begin actual const vals public static final Constant CONST1 = new Constant("a value"); public static final Constant CONST2 = new Constant("another value"); // ... etc ... } He goes into a detailed explanation about why this is the preferred idiom when dealing with constant classes, and makes a pretty strong case. One of the big benefits that I have personally encountered is that it allows you to pass "constant types" as method parameters. I.e.: Using our above example we could have a method with the signature doSomething(Constant c). I just found a link to this chapter: http://developer.java.sun.com/developer/Books/effectivejava/Chapter5.pdf

Posted by James Childers on February 27, 2003 at 02:11 PM MST #

Post a Comment:
  • HTML Syntax: Allowed
Click me to subscribe
Matt Raible is a Web Architecture Consultant specializing in open source frameworks.
« May 2012
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
  
       
Today

Recent Entries

Tag Cloud

abbie appfuse denver flex grails gwt hibernate jack java jsf linkedin maven myfaces rails roller skiing softwaresummit spring springmvc struts2 tapestry travel vacation webframeworks wicket