Константный дизайн параметров

Question

Я работаю с классом, который содержит константы или значения параметров, на которые, например, могут ссылаться все классы;

public class Parameters {
   public static final String JUMP_TO_VALUE = "Parameters.JUMP_TO_VALUE";
   public static final String EXCEPTION_ID  = "Parameters.EXCEPTION_ID";
}

Некоторые из базовых классов в моем приложении будут использовать значения параметров в классе Parameters следующим образом:

   mapOfValues.put( Parameters.JUMP_TO_VALUE, "some_value")

Это достаточно просто, у меня есть некоторые базовые значения в параметрах, которые будут использоваться большинством моих базовых классов. Во многих ситуациях мне потребуется добавить дополнительные параметры в класс Параметры , но я не хочу переполнять или загрязнять класс Параметры каждый раз, когда новый параметр определены. Я бы предпочел создать некоторый подкласс Параметры , например:

  public class NetworkParameters extends Parameters {
      public static final String HOST_NAME = "NetworkParameters.HOST_NAME";
      public static final String POST_NUM  = "NetworkParameters.PORT_NUM";
 }

Некоторые из моих конкретных классов будут использовать значения, содержащиеся в этом классе, вместо того, чтобы помещать их в класс Параметры .

Эти конкретные классы, которым требуется HOST_NAME, например, я не хочу, чтобы они ссылались на класс NetworkParameters , а скорее на класс Parameters .

Я уверен, что люди делали это раньше, но я ищу совет о том, как лучше всего реализовать этот дизайн.

Answer 1

Это просто невозможно, так, как вы это описываете.

Когда вы ссылаетесь на статические объекты, вы ссылаетесь на класс, в котором эти объекты объявлены. Проще говоря, если вы объявляете константу в классе NetworkParameters, она не существует в классе Parameters и недоступна как таковой.

Разделение огромного количества параметров на различные содержащие классы (которые не обязательно должны быть подтипами друг друга, поскольку это ничего не дает) является довольно хорошей практикой и часто используется. Почему у вас такое отвращение к простому использованию NetworkParameters.POST_NUM, так как это название параметра и оно звучит для меня совершенно разумно?

Одна вещь, которая может вам помочь (в зависимости от ваших собственных вкусов), - это использовать функцию Java 5 static import . Если в верхней части файла класса вы объявляете

import static the.package.name.Parameters.*;
import static other.package.NetworkParameters.*;

тогда вы сможете использовать все имена констант из обоих классов без какого-либо префикса. Это часто довольно приятно, когда очевидно, что происходит откуда - но это может стать кошмаром, если вы статически импортируете из нескольких классов, , особенно , если у вас нет IDE для обработки ссылки. для вас.

Но опять же - почему вы хотите назвать их Parameters.FOO, но хотите, чтобы они жили в отдельном классе? Любой подход (все в одном файле, разные константы в разных файлах) хорош и хорош, если вы делаете это полностью, но вы не можете волшебным образом изменить законы ссылок Java, потому что вам не нравится их внешний вид. : -)

Answer 2

Не думаю, что вы переусердствуете, если поместите много констант в один файл. Просто держите это хорошо организованным с хорошим форматированием и документацией. Я не думаю, что подклассификация здесь нужна. Подкласс подразумевает определенные отношения между объектами. Во-первых, вы на самом деле не создаете объект, поэтому создание подкласса здесь не совсем соответствует модели. Кроме того, использование здесь подкласса может только усложнить ситуацию. Например, вам придется импортировать несколько файлов Java, если вы хотите использовать несколько типов констант в другом классе.

Answer 3

Вы уверены, что хотите встроить эти значения в свой код?

Они звучат для меня как данные, которые вы хотите поместить в файл конфигурации, поэтому их можно легко изменять без необходимости перекомпиляции кода. Простой хэш пар имя-значение из файла конфигурации, упакованный так, чтобы он был доступен так, как вам нужно, может быть более гибким подходом к той же проблеме.