É uma prática ruim ter uma interface para definir constantes?

Joshua Bloch aconselha contra isso em seu livro Java efetivo :

That a class uses some constants internally is an implementation detail. Implementing a constant interface causes this implementation detail to leak into the classes 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.

Você pode obter o mesmo efeito com uma classe normal que define as constantes e, em seguida, usar import static com.example.Constants.*;

No nosso caso, estamos fazendo isso porque os valores das constantes representam um contrato para estados finais que uma implementação de serviço é obrigada a fornecer. Colocar essas constantes na interface especifica os estados finais como parte do contrato e, se qualquer implementação da interface não os utilizasse, ela não estaria fazendo o seu trabalho.

Às vezes, as constantes são detalhes de implementação. ÀS VEZES eles não são. Como de costume, um engenheiro precisa usar seu cérebro para decidir o que fazer e não confiar em um padrão ou prática abrangente.

Eu não acho que seja bom ter interfaces somente para constantes.

Mas se uma interface que define o comportamento (métodos que implementam classes devem implementar), tem constantes, tudo bem. Se "vazar alguns detalhes do implementador" na API, é porque é assim que deve ser. Eles também estão vazando que o implementador implementa métodos foo e bar.

Tome por exemplo a interface java.awt.Transparency. Tem constantes OPAQUE, BITMASK e TRANSLUCENT, mas também tem o método getTransparency ().

Se o designer colocar essas constantes lá, é porque ele achava que seria estável o suficiente para fazer parte da interface, como getTransparency () é.

Pense que é um ponto de vista mais popular em lugares onde o design por contrato é prevalente.
 Interfaces são contratos. Colocar constantes em interfaces significa que toda classe que cumpre o contrato concorda com o valor / conceito identificado pela constante.

Uma empresa em que trabalhei fez uso pesado de constantes ¹ importadas pela interface. Eu não sinto nenhum mal vindo disso.

A pergunta que você deve se fazer é: qual é a importância do namespace para você? No caso de constantes, isso é realmente uma classe. Se você tiver milhares de constantes, talvez não deseje que todas essas constantes estejam sempre disponíveis.

O mais interessante sobre as interfaces é que você tem o benefício de trabalhar de qualquer forma - incluir todos os namespaces necessários ou nenhum deles (e acessá-los explicitamente, com MyInterface.CONSTANT ). Praticamente a mesma coisa que import static MyInterface.* , mas um pouco mais óbvia.

^{1: Se você não está familiarizado com o Java, não estou falando da palavra-chave import , apenas me refiro a implements MyConstantsInterface}

Eu venho de um plano de fundo que é principalmente influenciado principalmente pelo "modo Ada" e pela "maneira .Net". Eu diria que não, provavelmente não é melhor declarar constantes dentro das interfaces. Tecnicamente não é permitido em c #.

A razão pela qual eu digo não é que uma interface é uma forma de contrato que define comportamento, não estado ou estrutura. Uma constante implica algum tipo de estado (primitivo) ou um aspecto de estado (composto ou agregado).

Eu posso apreciar o desejo de disponibilizar padrões e valores predefinidos para todos que implementam a interface, mas talvez o estado padrão seja melhor descrito em um objeto ou modelo abstrato ou de valor, em que os padrões teriam pelo menos um contexto mínimo.

Para um guia mais técnico: download.oracle.com/javase/1.5.0/docs/guide/language/static-import.html

Não, não é uma prática ruim geral.

O ponto é que constantes como qualquer outro artefato devem ser introduzidas sob as regras de visibilidade mínima e nível de abstração apropriado.

Usando a sintaxe apenas porque você pode é o verdadeiro problema.