Qual é a melhor maneira de implementar constantes em Java?

Eu vi exemplos como este:

public class MaxSeconds { public static final int MAX_SECONDS = 25; } 

e supostamente eu poderia ter uma class Constants para envolver as constantes, declarando-as como final estático. Eu não conheço praticamente nenhum Java e estou imaginando se essa é a melhor maneira de criar constantes.

Isso é perfeitamente aceitável, provavelmente até mesmo o padrão.

 (public/private) static final TYPE NAME = VALUE; 

onde TYPE é o tipo, NAME é o nome em maiúsculas com sublinhados para espaços e VALUE é o valor constante.

Eu recomendo não colocar suas constantes em suas próprias classs ou interfaces.

Como uma nota lateral: Variáveis ​​declaradas como final e mutáveis ​​podem ainda ser alteradas; no entanto, a variável nunca pode apontar para um object diferente.

Por exemplo:

 public static final Point ORIGIN = new Point(0,0); public static void main(String[] args){ ORIGIN.x = 3; } 

Isso é legal e ORIGIN seria um ponto em (3, 0).

Eu recomendaria altamente contra ter uma única class de constantes. Pode parecer uma boa ideia na época, mas quando os desenvolvedores se recusam a documentar constantes e a class cresce para englobar mais de 500 constantes que não são relacionadas entre si (estando relacionadas a aspectos completamente diferentes do aplicativo), geralmente se transforma no arquivo de constantes sendo completamente ilegível. Em vez de:

  • Se você tiver access ao Java 5+, use enums para definir suas constantes específicas para uma área de aplicativo. Todas as partes da área de aplicação devem se referir a enums, não a valores constantes, para essas constantes. Você pode declarar um enum similar a como você declara uma class. Os enums são talvez o recurso mais útil (e, possivelmente, único) do Java 5+.
  • Se você tiver constantes que sejam válidas apenas para uma class específica ou uma de suas subclasss, declare-as como protegidas ou públicas e coloque-as na class superior da hierarquia. Dessa forma, as subclasss podem acessar esses valores constantes (e se outras classs acessam-nas via público, as constantes não são válidas apenas para uma class em particular … o que significa que as classs externas que usam esta constante podem estar muito fortemente acopladas à class contendo a constante)
  • Se você tiver uma interface com comportamento definido, mas valores retornados ou valores de argumentos devem ser particulares, é perfeitamente aceitável definir constantes nessa interface para que outros implementadores tenham access a elas. No entanto, evite criar uma interface apenas para manter constantes: ela pode se tornar tão ruim quanto uma class criada apenas para manter constantes.

É uma prática ruim para usar interfaces apenas para manter constantes (chamado padrão de interface constante por Josh Bloch). Aqui está o que Josh aconselha:

Se as constantes estiverem fortemente ligadas a uma class ou interface existente, você deverá adicioná-las à class ou interface. Por exemplo, todas as classs primitivas numéricas em checkbox, como Integer e Double, exportam constantes MIN_VALUE e MAX_VALUE. Se as constantes forem melhor visualizadas como membros de um tipo enumerado, você deverá exportá-las com um tipo de enumeração . Caso contrário, você deve exportar as constantes com uma class de utilitário não instanciável.

Exemplo:

 // Constant utility class package com.effectivejava.science; public class PhysicalConstants { private PhysicalConstants() { } // Prevents instantiation public static final double AVOGADROS_NUMBER = 6.02214199e23; public static final double BOLTZMANN_CONSTANT = 1.3806503e-23; public static final double ELECTRON_MASS = 9.10938188e-31; } 

Sobre a convenção de nomenclatura:

Por convenção, esses campos têm nomes consistindo de letras maiúsculas, com palavras separadas por sublinhados. É fundamental que esses campos contenham valores primitivos ou referências a objects imutáveis.

Em Java eficaz (2ª edição), é recomendável usar enums em vez de ints estáticos para constantes.

Há um bom writeup em enums em Java aqui: http://java.sun.com/j2se/1.5.0/docs/guide/language/enums.html

Observe que no final desse artigo a pergunta é:

Então, quando você deve usar enums?

Com uma resposta de:

Sempre que precisar de um conjunto fixo de constantes

Apenas evite usar uma interface:

 public interface MyConstants { String CONSTANT_ONE = "foo"; } public class NeddsConstant implements MyConstants { } 

É tentador, mas viola o encapsulamento e desfaz a distinção das definições de class.

Eu uso a seguinte abordagem:

 public final class Constants { public final class File { public static final int MIN_ROWS = 1; public static final int MAX_ROWS = 1000; private File() {} } public final class DB { public static final String name = "oups"; public final class Connection { public static final String URL = "jdbc:tra-ta-ta"; public static final String USER = "testUser"; public static final String PASSWORD = "testPassword"; private Connection() {} } private DB() {} } private Constants() {} } 

Do que, por exemplo, eu uso Constants.DB.Connection.URL para ficar constante. Parece mais “object orientadamente” quanto a mim.

Criar constantes finais estáticas em uma class separada pode causar problemas. O compilador Java otimizará isso e colocará o valor real da constante em qualquer class que faça referência a ela.

Se depois você alterar a class ‘Constantes’ e não fizer uma re-compilation em outras classs que fazem referência a essa class, você terá uma combinação de valores antigos e novos sendo usados.

Em vez de pensar nelas como constantes, pense nelas como parâmetros de configuração e crie uma class para gerenciá-las. Os valores não são finais e consideram até o uso de getters. No futuro, quando você determinar que alguns desses parâmetros devem ser configuráveis ​​pelo usuário ou pelo administrador, será muito mais fácil fazer isso.

O erro número um que você pode cometer é criar uma class globalmente acessível chamada com um nome genérico, como constantes. Isso simplesmente fica cheio de lixo e você perde toda a capacidade de descobrir que parte do seu sistema usa essas constantes.

Em vez disso, as constantes devem entrar na class que “as possui”. Você tem uma constante chamada TIMEOUT? Ele provavelmente deve entrar em sua class Communications () ou Connection (). MAX_BAD_LOGINS_PER_HOUR? Vai para o usuário (). E assim por diante.

O outro uso possível é os arquivos .properties do Java quando “constantes” podem ser definidas em tempo de execução, mas não podem ser facilmente alteradas pelo usuário. Você pode empacotá-los em seus .jars e referenciá-los com o resourceLoader da class.

Esse é o caminho certo a seguir.

Geralmente, as constantes não são mantidas em classs “Constantes” separadas porque elas não são detectáveis. Se a constante é relevante para a class atual, mantê-los lá ajuda o próximo desenvolvedor.

Que tal uma enumeração?

Eu prefiro usar getters ao invés de constantes. Esses getters podem retornar valores constantes, por exemplo, public int getMaxConnections() {return 10;} , mas qualquer coisa que precise da constante passará por um getter.

Uma vantagem é que, se o seu programa ultrapassa a constante – você acha que precisa ser configurável – você pode simplesmente mudar como o getter retorna a constante.

O outro benefício é que, para modificar a constante, você não precisa recompilar tudo o que a utiliza. Quando você faz referência a um campo final estático, o valor dessa constante é compilado em qualquer bytecode que faça referência a ela.

Concordo que usar uma interface não é o caminho a percorrer. Evitar esse padrão até tem seu próprio item (# 18) no Java efetivo de Bloch.

Um argumento que Bloch faz contra o padrão de interface constante é que o uso de constantes é um detalhe de implementação, mas a implementação de uma interface para usá-los expõe esse detalhe de implementação em sua API exportada.

A public|private static final TYPE NAME = VALUE; padrão é uma boa maneira de declarar uma constante. Pessoalmente, eu acho melhor evitar fazer uma aula separada para abrigar todas as suas constantes, mas eu nunca vi uma razão para não fazer isso, além de preferência pessoal e estilo.

Se suas constantes puderem ser bem modeladas como uma enumeração, considere a estrutura de enumeração disponível em 1.5 ou posterior.

Se você estiver usando uma versão anterior à 1.5, ainda poderá retirar enumerações de tipos seguros usando classs Java normais. (Veja este site para mais sobre isso).

Com base nos comentários acima, acho que essa é uma boa abordagem para alterar a class de constante global antiquada (com variables ​​finais estáticas públicas) para seu equivalente semelhante a enum de uma maneira como esta:

 public class Constants { private Constants() { throw new AssertionError(); } public interface ConstantType {} public enum StringConstant implements ConstantType { DB_HOST("localhost"); // other String constants come here private String value; private StringConstant(String value) { this.value = value; } public String value() { return value; } } public enum IntConstant implements ConstantType { DB_PORT(3128), MAX_PAGE_SIZE(100); // other int constants come here private int value; private IntConstant(int value) { this.value = value; } public int value() { return value; } } public enum SimpleConstant implements ConstantType { STATE_INIT, STATE_START, STATE_END; } } 

Então eu posso referenciá-los como:

 Constants.StringConstant.DB_HOST 

Um bom design orientado a objects não deve precisar de muitas constantes publicamente disponíveis. A maioria das constantes deve ser encapsulada na class que precisa delas para fazer seu trabalho.

Há uma certa quantidade de opinião para responder isso. Para começar, as constantes em java geralmente são declaradas como públicas, estáticas e finais. Abaixo estão as razões:

 public, so that they are accessible from everywhere static, so that they can be accessed without any instance. Since they are constants it makes little sense to duplicate them for every object. final, since they should not be allowed to change 

Eu nunca usaria uma interface para um acessador / object CONSTANTS simplesmente porque geralmente espera-se que as interfaces sejam implementadas. Isso não parece engraçado:

 String myConstant = IMyInterface.CONSTANTX; 

Em vez disso, eu escolheria entre algumas maneiras diferentes, com base em algumas pequenas compensações, e isso depende do que você precisa:

 1. Use a regular enum with a default/private constructor. Most people would define constants this way, IMHO. - drawback: cannot effectively Javadoc each constant member - advantage: var members are implicitly public, static, and final - advantage: type-safe - provides "a limited constructor" in a special way that only takes args which match predefined 'public static final' keys, thus limiting what you can pass to the constructor 2. Use a altered enum WITHOUT a constructor, having all variables defined with prefixed 'public static final' . - looks funny just having a floating semi-colon in the code - advantage: you can JavaDoc each variable with an explanation - drawback: you still have to put explicit 'public static final' before each variable - drawback: not type-safe - no 'limited constructor' 3. Use a Class with a private constructor: - advantage: you can JavaDoc each variable with an explanation - drawback: you have to put explicit 'public static final' before each variable - you have the option of having a constructor to create an instance of the class if you want to provide additional functions related to your constants (or just keep the constructor private) - drawback: not type-safe 4. Using interface: - advantage: you can JavaDoc each variable with an explanation - advantage: var members are implicitly 'public static final' - you are able to define default interface methods if you want to provide additional functions related to your constants (only if you implement the interface) - drawback: not type-safe 

Qual é a melhor maneira de implementar constantes em Java?

Uma abordagem que devemos evitar : usar interfaces para definir constantes.

Criar uma interface especificamente para declarar constantes é realmente a pior coisa: ela anula o motivo pelo qual interfaces foram projetadas: definindo contrato (s) de método (s).

Mesmo que já exista uma interface para atender a uma necessidade específica, declarar as constantes nelas não faz sentido, pois as constantes não devem fazer parte da API e o contrato deve ser fornecido às classs do cliente.


Para simplificar, temos amplamente 4 abordagens válidas .

Com o campo static final String/Integer :

  • 1) usando uma class que declara constantes dentro, mas não apenas.
  • 1 variante) criando uma class dedicada a apenas declarar constantes.

Com o Java 5 enum :

  • 2) declarar o enum em uma class de finalidade relacionada (assim como uma class aninhada).
  • 2 variante) criando o enum como uma class autônoma (assim definida em seu próprio arquivo de class).

TLDR: Qual é o melhor caminho e onde localizar as constantes?

Na maioria dos casos, o caminho enum é provavelmente mais fino do que o modo static final String/Integer e, pessoalmente, acho que o modo static final String/Integer deve ser usado somente se tivermos boas razões para não usar enums.
E sobre onde devemos declarar os valores constantes, a ideia é pesquisar se existe uma única class existente que possua uma coesão funcional forte e específica com valores constantes. Se encontrarmos essa class, devemos usá-la como detentores de constantes . Caso contrário, a constante deve ser associada a nenhuma class específica.


static final String / static final Integer versus enum

O uso de enums é realmente uma maneira de considerar fortemente.
Enums têm uma grande vantagem sobre o campo constante String ou Integer .
Eles definem uma restrição de compilation mais forte. Se você definir um método que usa o enum como parâmetro, só poderá passar um valor de enum definido na class enum (ou nula).
Com String e Integer você pode substituí-los por quaisquer valores de tipo compatível e a compilation ficará bem, mesmo que o valor não seja uma constante definida nos campos static final String / static final Integer .

Por exemplo, abaixo de duas constantes definidas em uma class como campos de static final String :

 public class MyClass{ public static final String ONE_CONSTANT = "value"; public static final String ANOTHER_CONSTANT = "other value"; . . . } 

Aqui um método que espera ter uma dessas constantes como parâmetro:

 public void process(String constantExpected){ ... } 

Você pode invocá-lo desta maneira:

 process(MyClass.ONE_CONSTANT); 

ou

 process(MyClass.ANOTHER_CONSTANT); 

Mas nenhuma restrição de compilation impede que você a invoque dessa maneira:

 process("a not defined constant value"); 

Você teria o erro apenas em tempo de execução e somente se você fizer de cada vez uma verificação no valor transmitido.

Com enum, as verificações não são necessárias, pois o cliente só pode passar um valor enum em um parâmetro enum.

Por exemplo, aqui dois valores definidos em uma class enum (assim constante fora da checkbox):

 public enum MyEnum { ONE_CONSTANT("value"), ANOTHER_CONSTANT(" another value"); private String value; MyEnum(String value) { this.value = value; } ... } 

Aqui um método que espera ter um desses valores enum como parâmetro:

 public void process(MyEnum myEnum){ ... } 

Você pode invocá-lo desta maneira:

 process(MyEnum.ONE_CONSTANT); 

ou

 process(MyEnum.ANOTHER_CONSTANT); 

Mas a compilation nunca permitirá que você a invoque dessa maneira:

 process("a not defined constant value"); 

Onde devemos declarar as constantes?

Se o seu aplicativo contiver uma única class existente que possui uma coesão funcional forte e específica com os valores constantes, o 1) e o 2) parecerão mais intuitivos.
Geralmente, facilita o uso das constantes, se estas forem declaradas na class principal que as manipula ou que tem um nome muito natural para adivinhar que a encontraremos dentro.

Por exemplo, na biblioteca JDK, os valores da constante exponencial e pi são declarados em uma class que declara não apenas declarações de constantes ( java.lang.Math ).

  public final class Math { ... public static final double E = 2.7182818284590452354; public static final double PI = 3.14159265358979323846; ... } 

Os clientes que usam funções matemáticas dependem frequentemente da class Math . Assim, eles podem encontrar constantes facilmente e também podem lembrar onde E e PI são definidos de uma maneira muito natural.

Se a sua aplicação não contiver uma class existente que tenha uma coesão funcional muito específica e forte com os valores constantes, a variante 1 e a variante 2) parecerão mais intuitivas.
Geralmente, isso não facilita o uso das constantes se elas são declaradas em uma class que as manipula enquanto temos também 3 ou 4 outras classs que as manipulam tanto quanto e nenhuma dessas classs parece ser mais natural que outras para host valores constantes.
Aqui, definir uma class personalizada para manter apenas valores constantes faz sentido.
Por exemplo, na biblioteca JDK, a enumeração java.util.concurrent.TimeUnit não é declarada em uma class específica, pois não há realmente uma e apenas uma class específica do JDK que parece ser a mais intuitiva para mantê-la:

 public enum TimeUnit { NANOSECONDS { ..... }, MICROSECONDS { ..... }, MILLISECONDS { ..... }, SECONDS { ..... }, ..... } 

Muitas classs declaradas em java.util.concurrent utilizam: BlockingQueue , ArrayBlockingQueue , CompletableFuture , ExecutorService , … e realmente nenhuma delas parece mais apropriada para conter o enum.

Uma constante, de qualquer tipo, pode ser declarada criando uma propriedade imutável que dentro de uma class (que é uma variável de membro com o modificador final ). Normalmente, os modificadores static e public também são fornecidos.

 public class OfficePrinter { public static final String STATE = "Ready"; } 

Existem inúmeras aplicações em que o valor de uma constante indica uma seleção de uma n-tupla (por exemplo, enumeração ) de opções. Em nosso exemplo, podemos escolher definir um tipo enumerado que restringirá os possíveis valores atribuídos (ou seja, melhor segurança de tipos ):

 public class OfficePrinter { public enum PrinterState { Ready, PCLoadLetter, OutOfToner, Offline }; public static final PrinterState STATE = PrinterState.Ready; } 

Uma única class de constantes genéricas é uma má ideia. As constantes devem ser agrupadas com a class com a qual elas estão mais logicamente relacionadas.

Em vez de usar variables ​​de qualquer tipo (especialmente enums), sugiro que você use methods. Crie um método com o mesmo nome da variável e faça com que ele retorne o valor atribuído à variável. Agora, exclua a variável e substitua todas as referências a ela por chamadas para o método recém-criado. Se você acha que a constante é genérica o suficiente para que você não precise criar uma instância da class apenas para usá-la, então torne o método constant um método de class.

FWIW, um valor de tempo limite em segundos provavelmente deve ser uma configuração (leia a partir de um arquivo de propriedades ou através de injeção como no Spring) e não uma constante.

Qual é a diferença

1

 public interface MyGlobalConstants { public static final int TIMEOUT_IN_SECS = 25; } 

2

 public class MyGlobalConstants { private MyGlobalConstants () {} // Prevents instantiation public static final int TIMEOUT_IN_SECS = 25; } 

e usando MyGlobalConstants.TIMEOUT_IN_SECS sempre que precisarmos dessa constante. Eu acho que ambos são iguais.

Eu não chamaria a class da mesma forma (além do case) como a constante … Eu teria no mínimo uma class de “Configurações”, ou “Valores”, ou “Constantes”, onde todas as constantes viveriam. Se eu tiver um grande número deles, eu os agruparia em classs constantes lógicas (UserSettings, AppSettings, etc.)

Para dar um passo adiante, você pode colocar constantes usadas globalmente em uma interface para que elas possam ser usadas em todo o sistema. Por exemplo

 public interface MyGlobalConstants { public static final int TIMEOUT_IN_SECS = 25; } 

Mas não o implemente. Basta se referir a eles diretamente no código através do nome completo da class.

Para constantes, Enum é uma melhor escolha IMHO. Aqui está um exemplo

class pública myClass {

 public enum myEnum { Option1("String1", 2), Option2("String2", 2) ; String str; int i; myEnum(String str1, int i1) { this.str = str1 ; this.i1 = i } } 

Uma das maneiras de fazer isso é criar uma class ‘Global’ com os valores constantes e fazer uma importação estática nas classs que precisam acessar a constante.

static final é a minha preferência, eu só usaria um enum se o item fosse de fato enumerável.

Eu uso static final para declarar constantes e ir com a notação de nomenclatura ALL_CAPS. I have seen quite a few real life instances where all constants are bunched together into an interface. A few posts have rightly called that a bad practice, primarily because that’s not what an interface is for. An interface should enforce a contract and should not be a place to put unrelated constants in. Putting it together into a class that cannot be instantiated (through a private constructor) too is fine if the constant semantics don’t belong to a specific class(es). I always put a constant in the class that it’s most related to, because that makes sense and is also easily maintainable.

Enums are a good choice to represent a range of values, but if you are storing standalone constants with an emphasis on the absolute value (eg. TIMEOUT = 100 ms) you can just go for the static final approach.

I agree with what most are saying, it is best to use enums when dealing with a collection of constants. However, if you are programming in Android there is a better solution: IntDef Annotation .

 @Retention(SOURCE) @IntDef({NAVIGATION_MODE_STANDARD, NAVIGATION_MODE_LIST,NAVIGATION_MODE_TABS}) public @interface NavigationMode {} public static final int NAVIGATION_MODE_STANDARD = 0; public static final int NAVIGATION_MODE_LIST = 1; public static final int NAVIGATION_MODE_TABS = 2; ... public abstract void setNavigationMode(@NavigationMode int mode); @NavigationMode public abstract int getNavigationMode(); 

IntDef annotation is superior to enums in one simple way, it takes significantly less space as it is simply a compile-time marker. It is not a class, nor does it have the automatic string-conversion property.

It is BAD habit and terribly ANNOYING practice to quote Joshua Bloch without understanding the basic ground-zero fundamentalism.

I have not read anything Joshua Bloch, so either

  • he is a terrible programmer
  • or the people so far whom I find quoting him (Joshua is the name of a boy I presume) are simply using his material as religious scripts to justify their software religious indulgences.

As in Bible fundamentalism all the biblical laws can be summed up by

  • Love the Fundamental Identity with all your heart and all your mind
  • Love your neighbour as yourself

and so similarly software engineering fundamentalism can be summed up by

  • devote yourself to the ground-zero fundamentals with all your programming might and mind
  • and devote towards the excellence of your fellow-programmers as you would for yourself.

Also, among biblical fundamentalist circles a strong and reasonable corollary is drawn

  • First love yourself. Because if you don’t love yourself much, then the concept “love your neighbour as yourself” doesn’t carry much weight, since “how much you love yourself” is the datum line above which you would love others.

Similarly, if you do not respect yourself as a programmer and just accept the pronouncements and prophecies of some programming guru-nath WITHOUT questioning the fundamentals, your quotations and reliance on Joshua Bloch (and the like) is meaningless. And therefore, you would actually have no respect for your fellow-programmers.

The fundamental laws of software programming

  • laziness is the virtue of a good programmer
  • you are to make your programming life as easy, as lazy and therefore as effective as possible
  • you are to make the consequences and entrails of your programming as easy, as lazy and therefore as effective as possible for your neigbour-programmers who work with you and pick up your programming entrails.

Interface-pattern constants is a bad habit ???

Under what laws of fundamentally effective and responsible programming does this religious edict fall into ?

Just read the wikipedia article on interface-pattern constants ( https://en.wikipedia.org/wiki/Constant_interface ), and the silly excuses it states against interface-pattern constants.

  • Whatif-No IDE? Who on earth as a software programmer would not use an IDE? Most of us are programmers who prefer not to have to prove having macho aescetic survivalisticism thro avoiding the use of an IDE.

    • Also – wait a second proponents of micro-functional programming as a means of not needing an IDE. Wait till you read my explanation on data-model normalization.
  • Pollutes the namespace with variables not used within the current scope? It could be proponents of this opinion

    • are not aware of, and the need for, data-model normalization
  • Using interfaces for enforcing constants is an abuse of interfaces. Proponents of such have a bad habit of

    • not seeing that “constants” must be treated as contract. And interfaces are used for enforcing or projecting compliance to a contract.
  • It is difficult if not impossible to convert interfaces into implemented classs in the future. Hah …. hmmm … ???

    • Why would you want to engage in such pattern of programming as your persistent livelihood? IOW, why devote yourself to such an AMBIVALENT and bad programming habit ?

Whatever the excuses, there is NO VALID EXCUSE when it comes to FUNDAMENTALLY EFFECTIVE software engineering to delegitimize or generally discourage the use of interface constants.

It doesn’t matter what the original intents and mental states of the founding fathers who crafted the United States Constitution were. We could debate the original intents of the founding fathers but all I care is the written statements of the US Constitution. And it is the responsibility of every US citizen to exploit the written literary-fundamentalism, not the unwritten founding-intents, of the US Constitution.

Similarly, I do not care what the “original” intents of the founders of the Java platform and programming language had for the interface. What I care are the effective features the Java specification provides, and I intend to exploit those features to the fullest to help me fulfill the fundamental laws of responsible software programming. I don’t care if I am perceived to “violate the intention for interfaces”. I don’t care what Gosling or someone Bloch says about the “proper way to use Java”, unless what they say does not violate my need to EFFECTIVE fulfilling fundamentals.

The Fundamental is Data-Model Normalization

It doesn’t matter how your data-model is hosted or transmitted. Whether you use interfaces or enums or whatevernots, relational or no-SQL, if you don’t understand the need and process of data-model normalization.

We must first define and normalize the data-model of a set of processes. And when we have a coherent data-model, ONLY then can we use the process flow of its components to define the functional behaviour and process blocks a field or realm of applications. And only then can we define the API of each functional process.

Even the facets of data normalization as proposed by EF Codd is now severely challenged and severely-challenged. eg his statement on 1NF has been criticized as ambiguous, misaligned and over-simplified, as is the rest of his statements especially in the advent of modern data services, repo-technology and transmission. IMO, the EF Codd statements should be completely ditched and new set of more mathematically plausible statements be designed.

A glaring flaw of EF Codd’s and the cause of its misalignment to effective human comprehension is his belief that humanly perceivable multi-dimensional, mutable-dimension data can be efficiently perceived thro a set of piecemeal 2-dimensional mappings.

The Fundamentals of Data Normalization

What EF Codd failed to express.

Within each coherent data-model, these are the sequential graduated order of data-model coherence to achieve.

  1. The Unity and Identity of data instances.
    • design the granularity of each data component, whereby their granularity is at a level where each instance of a component can be uniquely identified and retrieved.
    • absence of instance aliasing. ie, no means exist whereby an identification produces more than one instance of a component.
  2. Absence of instance crosstalk. There does not exist the necessity to use one or more other instances of a component to contribute to identifying an instance of a component.
  3. The unity and identity of data components/dimensions.
    • Presence of component de-aliasing. There must exist one definition whereby a component/dimension can be uniquely identified. Which is the primary definition of a component;
    • where the primary definition will not result in exposing sub-dimensions or member-components that are not part of an intended component;
  4. Unique means of component dealiasing. There must exist one, and only one, such component de-aliasing definition for a component.
  5. There exists one, and only one, definition interface or contract to identify a parent component in a hierarchical relationship of components.
  6. Absence of component crosstalk. There does not exist the necessity to use a member of another component to contribute to the definitive identification of a component.
    • In such a parent-child relationship, the identifying definition of a parent must not depend on part of the set of member components of a child. A member component of a parent’s identity must be the complete child identity without resorting to referencing any or all of the children of a child.
  7. Preempt bi-modal or multi-modal appearances of a data-model.
    • When there exists two candidate definitions of a component, it is an obvious sign that there exists two different data-models being mixed up as one. That means there is incoherence at the data-model level, or the field level.
    • A field of applications must use one and only one data-model, coherently.
  8. Detect and identify component mutation. Unless you have performed statistical component analysis of huge data, you probably do not see, or see the need to treat, component mutation.
    • A data-model may have its some of its components mutate cyclically or gradually.
    • The mode may be member-rotation or transposition-rotation.
    • Member-rotation mutation could be distinct swapping of child components between components. Or where completely new components would have to be defined.
    • Transpositional mutation would manifest as a dimensional-member mutating into an attribute, vice versa.
    • Each mutation cycle must be identified as a distinct data-modal.
  9. Versionize each mutation. Such that you can pull out a previous version of the data model, when perhaps the need arise to treat an 8 year old mutation of the data model.

In a field or grid of inter-servicing component-applications, there must be one and only one coherent data-model or exists a means for a data-model/version to identify itself.

Are we still asking if we could use Interface Constants? Really ?

There are data-normalization issues at stake more consequential than this mundane question. IF you don’t solve those issues, the confusion that you think interface constants cause is comparatively nothing. Zilch.

From the data-model normalization then you determine the components as variables, as properties, as contract interface constants.

Then you determine which goes into value injection, property configuration placeholding, interfaces, final strings, etc.

If you have to use the excuse of needing to locate a component easier to dictate against interface constants, it means you are in the bad habit of not practicing data-model normalization.

Perhaps you wish to compile the data-model into a vcs release. That you can pull out a distinctly identifiable version of a data-model.

Values defined in interfaces are completely assured to be non-mutable. And shareable. Why load a set of final strings into your class from another class when all you need is that set of constants ??

So why not this to publish a data-model contract? I mean if you can manage and normalize it coherently, why not? …

 public interface CustomerService { public interface Label{ char AssignmentCharacter = ':'; public interface Address{ String Street = "Street"; String Unit= "Unit/Suite"; String Municipal = "City"; String County = "County"; String Provincial = "State"; String PostalCode = "Zip" } public interface Person { public interface NameParts{ String Given = "First/Given name" String Auxiliary = "Middle initial" String Family = "Last name" } } } } 

Now I can reference my apps’ contracted labels in a way such as

 CustomerService.Label.Address.Street CustomerService.Label.Person.NameParts.Family 

This confuses the contents of the jar file? As a Java programmer I don’t care about the structure of the jar.

This presents complexity to osgi-motivated runtime swapping ? Osgi is an extremely efficient means to allow programmers to continue in their bad habits. There are better alternatives than osgi.

Or why not this? There is no leakage of of the private Constants into published contract. All private constants should be grouped into a private interface named “Constants”, because I don’t want to have to search for constants and I am too lazy to repeatedly type “private final String”.

 public class PurchaseRequest { private interface Constants{ String INTERESTINGName = "Interesting Name"; String OFFICIALLanguage = "Official Language" int MAXNames = 9; } } 

Perhaps even this:

 public interface PurchaseOrderConstants { public interface Properties{ default String InterestingName(){ return something(); } String OFFICIALLanguage = "Official Language" int MAXNames = 9; } } 

The only issue with interface constants worth considering is when the interface is implemented.

This is not the “original intention” of interfaces? Like I would care about the “original intention” of the founding fathers in crafting the US Constitution, rather than how the Supreme Court would interpret the written letters of the US Constitution ???

After all, I live in the land of the free, the wild and home of the brave. Be brave, be free, be wild – use the interface. If my fellow-programmers refuse to use efficient and lazy means of programming, am I obliged by the golden rule to lessen my programming efficiency to align with theirs? Perhaps I should, but that is not an ideal situation.