Подтвердить что ты не робот

Идеальный способ организовать Java-константы

У нас есть огромные проекты, основанные на старом jdk 1.4. Мы перенесли веб-приложение в JDK 1.6, но в коде существует много неэффективных практик и плохой дизайн.

В основной точке боли огромные классы Java 2500+ строк кода в одном файле java. Так много таких файлов.

В попытке реорганизовать классы, которые я начал, удалили константы и поместили константы в другой файл Constants.java. но так как существует огромное количество констант, находящихся вне приложения, файл констант имеет риск роста до огромных размеров.

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

4b9b3361

Ответ 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

Ответ 8

Я думаю, что если у вас несколько java файлов более чем на 2500 LOC, решение о том, где разместить константы, должно быть наименьшей из ваших проблем. Вы должны составить четкое представление о том, как будет выглядеть реструктурированная система. Это, вероятно, гораздо сложнее, чем решить, где придерживаться констант и других синтаксических соображений, но это необходимо сделать в первую очередь.