Name for constants

[Andreas Johansson]

Hi!
This may seem like a strange question, but I want to know a suitable name for a specific form of constants.
If I have these in an interface:
public static final short ADDED = 30;
public static final short DELETED = 31;
public static final short UPDATED = 32;
...
I don't use their value at all, just to give more readable code when I need to be able to pass more info than a boolean can handle and don't want to make a class for it.
One usage could be:
object.setStatus(DELETED);
What could then be a suitable name for this interface??? (not Constants, I already have another one with that name for "real" constants)
/Andreas

[Erik Pragt]

ehhh...Nice question
action??
or
status??
Greetings, Erik

[Andreas Johansson]

Originally posted by Erik Pragt:
ehhh...Nice question
action??
or
status??
Greetings, Erik

Hi and thanks for your reply!
Both names are okay for some of the constants, but not for every one. I have a lot of them of different kinds:
PRIMARY_LOG, ERROR_LOG, NEW, UPDATE, DELETE, LANGUAGE_CHANGE, NONE, CONNECT, FORWARD, BACKWARD, etc.
I think there exist some special name for this kind of constants, but I can't remember it. =(
/Andreas

[Peter den Haan]

They are enumerations. In any case, I would suggest using typed objects, rather than integers, for enumerations wherever possible:

interface StateEnum {
   StateEnum ADDED = new StateEnum() { };
   StateEnum DELETED = new StateEnum() { };
   StateEnum NEW = new StateEnum() { };
}

Remember, interface members are implicitly public, static and final. If you want to kit out your enumeration with some behaviour, you add a little implementation class:

interface StateEnum {
   StateEnum ADDED = new StateEnumImpl(30);
   StateEnum DELETED = new StateEnumImpl(31);
   StateEnum NEW = new StateEnumImpl(32);
   /** returns an integer representation for the state */
   public int intValue();
   /** implementation class */
   class StateEnumImpl {
      private final int value;
      StateEnumImpl(int value) {
         this.value = value;
      }
      public int intValue() {
         return value;
      }
   }
}

For enumerations that have no behaviour, you can get easy access to the constants by simply implementing the interface, although it is debatable whether that is good practice or not.
Why objects? For type safety. For instance, a method doSomething(StateEnum state, int times) is safe, the integer-enumerated equivalent doSomething(int state, int times) is not as the compiler will not detect it when you can accidentally reverse the arguments. If you have to use integers for enumerations, use a short type to improve compile-time type checking somewhat.
Don't make the mistake of thinking that object enumerations are less efficient than integer enumerations. They are instantiated just once when the application starts, you compare them simply using the == operator, and they have (on 32-bit JVMs at least) the same memory footprint as an int.
- Peter

[This message has been edited by Peter den Haan (edited October 23, 2001).]

[Cindy Glass]

I was just reading Joshua Blochs "Effective Java" and he addresses this topic.
His advice is to never have an interface whose only purpose is to provide constants, an interface should be used ONLY to describe "type" (Item 19 in his book).
His preference is to use a typesafe enum class over an interface (Item 21), and give it a private constructor. Then just reference the fields as needed. This way you can add constants to the class without having to recompile the classes that are using it (as you would with an interface).
Which is of course what Peter implied when he doubted how good a practice it was to use an interface.

[Andreas Johansson]

Originally posted by Cindy Glass:

His advice is to never have an interface whose only purpose is to provide constants, an interface should be used ONLY to describe "type" (Item 19 in his book).

I will check it out, if I get the possibility. =)
<cut>

Which is of course what Peter implied when he doubted how good a practice it was to use an interface.

Thank you both, Cindy and Peter, for your reply. Of course you are right. An interface concisting of shorts arn't as typesafe as it should be. Still it is what we currently have. When it is time for refactoring that might change.
But still it didn't answer my question. What should be a suitable name for the interface?? (Not Constants or Enumerations) Even if I make it the way Peter suggested, it will still need a name.
Best regards
/Andreas

[Peter den Haan]

I thought enumeration was the name you were looking for...
- Peter

[Andreas Johansson]

Originally posted by Peter den Haan:
I thought enumeration was the name you were looking for...
- Peter

I thought about Enumerations earlier, but it felt too technical and close to the class Enumeration and also was not so describing.
Maybe "actions", "status", "codes" or something closer to them is better. Eventhough I'm not sure about any of them. (currently the interface is called "GeneralCodes" which is the reason I want to change it)
This might seem as a small thing, but names are important!
Best regards
/Andreas

[shilpa kulkarni]

How about "Application", since these constants belong to this particular application.
Then you could use -
Application.PRIMARY_LOG, Application.ERROR_LOG, Application.UPDATE, Application.DELETE, etc.
[This message has been edited by shilpa kulkarni (edited October 24, 2001).]

[Cindy Glass]

What should be a suitable name for the interface??

Well, have you considered Wilbur?

(sorry )
OK perhaps Operations or Ops, because that is what you are trying to define.

[Michael Ernest]

It's hard to kick the C habit sometimes, so I use interfaces for constants. And I'd do it again!
Seriously, though, typesafety for me isn't a concern unless I'm really planning to see my code liberally extended and the documentation ignored. If someone out there is actually desperate enough to buy my software, it's rarely an issue to rewrite the interface to address that. With that in mind, you can probably guess that I stay away from primitives (can't shake the SmallTalk either).
I'll name a catch-all interface _Toolkit, which is then extended by an interface suitable to the application, e.g., MFEToolkit.
Three contants I can't live without, although as practice they do imply a nasty slippery slope of future problems:
public static final PrintStream stdout = System.out;
public static final PrintStream stderr = System.err;
public static final InputStream stdin = System.in;
------------------
Michael Ernest, co-author of: The Complete Java 2 Certification Study Guide
[This message has been edited by Michael Ernest (edited October 24, 2001).]

[Andreas Johansson]

Thank you all for your replies, they are very appreciated!
But I still haven't found that "perfect name" yet so any further suggestions are welcome. Good thinking anyhow! =)

Best regards
Andreas

[Michael Bruesch]

To totally NOT answer your question Andreas, I agree with what Cindy and "Effective Java" says, don't use interfaces for strictly constants. That's hacking/cheating, whatever you want to call it. On your subject Andreas, call it "TempClassName" for now, finish the important stuff first, then worry about the piddly stuff later. There's always the Find and Replace All option to change it up at the end.
------------------
Michael J Bruesch
Codito, ergo sum...
I code, therefore I am.
My Java Games, I'm quite proud

[Andreas Johansson]

Originally posted by Michael Bruesch:
To totally NOT answer your question Andreas, I agree with what Cindy and "Effective Java" says, don't use interfaces for strictly constants. That's hacking/cheating, whatever you want to call it. On your subject Andreas, call it "TempClassName" for now, finish the [b]important stuff first, then worry about the piddly stuff later. There's always the Find and Replace All option to change it up at the end.
[/B]

Well, we have them right now, and they been around for a while. So I guess they will stay at least this version out. And therefore some suggestion for a more descriptive name is needed....
/Andreas

[Jane Griscti]

Andreas,
If you are going to keep them as constants then why not just name them that way 'StateConstants' or 'StatusConstants'?? The whole point of a name is to clearly communicate the reason the class or interface exists. It doesn't have to be the perfect name, it just has to make sense in terms of the application.
Hope that helps.

[Andreas Johansson]

Originally posted by Peter den Haan:
[B]

interface StateEnum {
   StateEnum ADDED = new StateEnum() { };
   StateEnum DELETED = new StateEnum() { };
   StateEnum NEW = new StateEnum() { };
}

Remember, interface members are implicitly public, static and final. If you want to kit out your enumeration with some behaviour, you add a little implementation class:

interface StateEnum {
   StateEnum ADDED = new StateEnumImpl(30);
   StateEnum DELETED = new StateEnumImpl(31);
   StateEnum NEW = new StateEnumImpl(32);
   /** returns an integer representation for the state */
   public int intValue();
   /** implementation class */
   class StateEnumImpl {
      private final int value;
      StateEnumImpl(int value) {
         this.value = value;
      }
      public int intValue() {
         return value;
      }
   }
}

[This message has been edited by Peter den Haan (edited October 23, 2001).][/B]

Hi again!
I have tried to implement your suggestion as follows (quite like yours:

public interface StateStatus {
  StateStatusImpl ADDED = new StateStatusImpl(30);
  StateStatusImpl DELETED = new StateStatusImpl(31);
  StateStatusImpl NEW = new StateStatusImpl(32);
  public int intValue();
  /**
   * implementation class
   */
  class StateStatusImpl {
    private final int value;
    StateStatusImpl(int value) {
      this.value = value;
    }
    public int intValue() {
      return value;
    }
  }
}

But how do I use it? I have tried some ways like:

public void testStatus(StateStatus state) {
  if(state == StateStatus.ADDED) {
    System.out.println("Added item");
  } else if(state == StateStatus.NEW) {
    System.out.println("A new item");
  }
}
...
testStatus(StateStatus.NEW);
...

But this won't compile and gives me:
"Server.java": Error #: 300 : method testStatus(com.termmate.StateStatus.StateStatusImpl) not found in class com.termmate.server.Server at line 127, column 5
I changed your "StateStatus ADDED = new..." to "StateStatusImpl ADDED = new..." since it wouldn't complie otherwise. I guess there are something wrong with that part...
Please help.
/Andreas

[Bosun Bello]

The compiler can't find the interface in the package "com.termate" You will need to add the interface definition to the package. I am assuming it exists somewhere in your directory structure.




------------------
Bosun
SCJP for the Java� 2 Platform

[Peter den Haan]

Your ...Impl class doesn't actually implement the interface...
- Peter

[Andreas Johansson]

Originally posted by Peter den Haan:
Your ...Impl class doesn't actually implement the interface...
- Peter

Ah, what a stupied misstake! Sorry to bother you... Friday afternoon, you know. =)
Thanks!
/Andreas

[saager mhatre]

I guess one can't totally disapprove the use of interfaces for providing constants. It seems like the most effective option when exposing a large number of public constants. I allows for portability of the constants without the excess baggage of the method definitions. A look at the SwingConstants interface kind'a puts the point through.

The discussion on using objects for type safety is an entirely different though debateable issue!

[David Duran]

I didn't take the time to read through this entire post, but this article seems like a very important read for those who suggested type safe enumerations:
http://www.javaworld.com/javaworld/javatips/jw-javatip122.html