directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <>
Subject Re: Code review - constants in interface
Date Mon, 22 Nov 2010 13:50:52 GMT
AFAIK, the best pattern for that is to use a final with a private
constructor and declare public static final fields in it.

public class Constants {
	private Constants() {
		// non-instantiable class

	public static final String TYPE = "type";

This avoids all the problems as it forces the user to import the
constants (and not inheriting the interface).

Just my 2 cents.

On Mon, Nov 22, 2010 at 14:45, Felix Knecht <> wrote:
> Hi devs
> We do have several interfaces [1] just being used as constants holder (and
> even more, not all of them are declared as static fields) which isn't the
> most preferable construct:
> "The constant interface pattern is a poor use of interfaces. That a class
> uses some constants internally is an implementation detail. Implementing a
> constant interface causes this implementation detail to leak into the
> class's exported API. It is of no consequence to the users of a class that
> the class implements a constant interface. In fact, it may even confuse
> them. Worse, it represents a commitment: if in a future release the class is
> modified so that it no longer needs to use the constants, it still must
> implement the interface to ensure binary compatibility. If a nonfinal class
> implements a constant interface, all of its subclasses will have their
> namespaces polluted by the constants in the interface." [2]
> Is there any need to have them declared in an interface or is it just a poor
> use?
> If there's no need we they could be implemented e.g. as enum or as static
> class an them static import could be used.
> Regards
> Felix
> [1] e.g.
> (even nowhere
> referenced in the code)
> (even nowhere
> referenced in the code)
> [2] Joshua Bloch, "Effective Java (2nd Edition)"

Guillaume Nodet
Open Source SOA

View raw message