Mike Schilling wrote:
Lew wrote:
Qu0ll wrote:
A better alternative is to use an interface if the user name is
constant like:
public interface UserConstants {
public static final String USER_NAME = "sahm";
}
This terrible idea is known in the industry as the Constant
Interface
Antipattern.
Interfaces should be used to define types, not to hold constants.
Use classes to hold constants.
The antipattern is to implement the interface to be able to use the
simple names for the constants. It's quite sensible for, say,
org.w3c.Node to define the node type constants, since in DOM
programming you should always use interfaces, not concrete classes.
Likewise, if InputStream were an interface (as it should be), It
would make perfect sense for it to define
int EOF = -1;
It is not a shoe-in that InputStream should have been an interface,
though the case is strong.
I don't agree that constants in the interface make sense even for
the
DOM scenario. Interfaces exist to be implemented, to provide type
identification. A separate static-member class is a better choice
for constants, e.g., for the DOM I'd recommend a NodeConstants
class.
You've stated your opinion pretty strongly. Can you give the reasons