Идеальный способ организовать Java-константы
У нас есть огромные проекты, основанные на старом jdk 1.4. Мы перенесли веб-приложение в JDK 1.6, но в коде существует много неэффективных практик и плохой дизайн.
В основной точке боли огромные классы Java 2500+ строк кода в одном файле java. Так много таких файлов.
В попытке реорганизовать классы, которые я начал, удалили константы и поместили константы в другой файл Constants.java. но так как существует огромное количество констант, находящихся вне приложения, файл констант имеет риск роста до огромных размеров.
Я был бы признателен за отзывы о том, какая стратегия разработчики принимают, чтобы сохранить код чистым и поддерживаемым.
Ответы
Ответ 1
Сохраняйте свои константы в классе, с которым они связаны, не чувствуйте себя обязанным их извлекать. Он может очистить код класса, но смешивание несвязанных констант в файле не является улучшением.
Держите вещи вместе.
А также вы можете конвертировать их в Enums, когда это возможно/полезно (но это может потребовать некоторого рефакторинга).
Ответ 2
Помещение всех констант в один файл - ужасная идея! Особенно анти-шаблон uber-Constant, где все константы находятся в Interface
, которые каждый класс должен implement
. 10 способов воскресенья ужасно! Это была плохая идея, когда люди начали делать это еще в начале 1990 года перед Java! Это определенно плохая идея в 2012 году.
Это означает, что вы смешиваете много несвязанной информации и создаете ненужные зависимости каждый раз, когда вы импортируете этот файл uber-Constants. Вещи, которые идут вместе, должны быть вместе в Enum
или, по крайней мере, в Class
, который использует их в качестве аргументов для своих методов, чтобы при их изменении вы знали, как легко провести анализ последствий.
Представьте константы Color
, смешанные с константами DaysOfTheWeek
, смешанными с другими константами бизнес-домена, и в одном файле будут сотни, если не тысячи этих вещей. Как это можно считать хорошей идеей? В каждом несобранном случае лучше использовать Enum
, являющийся public inner
членом Class
.
Это также означает, что у вас есть одно плоское пространство имен, чтобы попытаться создать имена, которые не конфликтуют, тогда они не очевидны, к чему они принадлежат, и как их следует использовать. Это никогда не является положительным упражнением.
При проектировании и рефакторинге вы всегда должны:
Стремитесь к высокой степени сцепления, это означает, что все связанные вещи связаны как можно ближе друг к другу.
Стремитесь к свободному соединению, это означает, что не позволяйте несвязанным вещам течь в другие несвязанные области.
Стремитесь к самодокументируемому поддерживаемому коду, десятки или сотни деклараций private static final String/int
, все смешанные вместе, не соответствуют этому определению любым стандартом!
В 2012 году константы C-стиля являются слабым решением, когда теперь у вас Enum
как инструмент, вы должны сосредоточиться на преобразовании как можно большего числа этих групп констант в Enum
, где это возможно. Enum
безопасен по типу и может иметь к нему другие атрибуты, свойства и поведения, чтобы сделать их intelligent
. Это путь вниз.
Ответ 3
Просто поместив константы в файл Constant.java
, на мой взгляд, это не делает смысла (это просто отодвигает проблему). Но иногда я использую их для перегруппировки, чтобы очистить вещи и использовать несколько файлов для их перегруппировки: DatabaseConstants.java
, GraphicConstants.java
и так далее...
и, конечно, использование перечислений также может быть полезно (и передовой опыт).
edit: если быть точным, я действительно работаю с Java ME-приложением, так что это просто способ "имитировать" перечисления, которые у меня не могут быть, с "контролируемой лексикой" в абстрактных классах (я пропускаю все Java EE функции...)
Ответ 4
Для тех, кто посещает эту страницу.
Если вы не хотите поддерживать несколько файлов констант, ниже это лучший способ организовать.
public interface Constants {
public static final String CREATE_USER = "createUser";
// Nested Interface.
public interface ProjectConstants {
public static final String CREATE_PROJECT = "createProject";
public static final String INVALID_SESSION = "Invalid Session";
// As you know they are implicity public static final.
}
}// Accessed as:
Constants.ProjectConstants.CREATE_PROJECT
Ответ 5
Я хотел бы поделиться шаблоном проектирования для констант, которые я видел несколько лет назад, которые могут помочь.
Начните с создания файла BaseConstant. Это будет содержать все ваши глобальные константы, которые могут использовать все пакеты.
Теперь в каждом подпакете вашего приложения создайте файл Constants, который будет связан только с подпакетом. Так что если бы у вас было. подпакет под названием "Вход" содержит только константы, связанные с входом в систему. Но ключ состоит в том, чтобы продлить действие BaseConstants. таким образом вы можете увидеть все глобальные константы в модуле IDE, но когда вы открываете файл, вы видите только свои константы пакета. что, будучи сказанным, я думаю, что постоянные файлы могут получить действительно тяжелые и повторяющиеся значения и трудно читать.
Вот что я имею в виду.
public class BaseConstants{
public static final String GLOBAL1= "GLOBAL string";
public static final String GLOBAL2= "another GLOBAL string";
}
Теперь во всех ваших других пакетах создайте такие файлы:
class MyPackageConstants extends BaseConstants{
public static final String LOCAL1 = "local String"
public static final String LOCAL2= "ANOTHER LOCAL string";
}
в вашей среде IDE при вводе "MyPackageConstants". вы должны увидеть все константы для всего приложения.
Ответ 6
Я никогда не слышал о том, чтобы поместить все константы в один файл java. Лучший способ - поместить константы, совпадающие с классами сами по себе, но назовите их заглавной буквой и подчеркиваниями, подобными этому: EXAMPLE_CONSTANT
Ответ 7
Вы пытались использовать Enums для всех ваших констант? Мне сказали, что это предпочтительный путь с Java 1.5.
http://docs.oracle.com/javase/1.5.0/docs/guide/language/enums.html
Ответ 8
Я думаю, что если у вас несколько java файлов более чем на 2500 LOC, решение о том, где разместить константы, должно быть наименьшей из ваших проблем. Вы должны составить четкое представление о том, как будет выглядеть реструктурированная система.
Это, вероятно, гораздо сложнее, чем решить, где придерживаться констант и других синтаксических соображений, но это необходимо сделать в первую очередь.