Инкапсуляция API настроек Java
Раньше у меня был собственный класс предпочтений для моих приложений. Для своего следующего хобби-проекта я хотел перейти на API настроек. Но для функций put и get требуется значение по умолчанию, и я не хочу распространять значения по умолчанию по всем исходным файлам. Несмотря на то, что мой проект невелик, я не могу представить, чтобы значения по умолчанию менялись во всем исходном коде. Как вы, ребята, используете api? Я подумываю обернуть api настроек в другой класс, но тогда какой смысл использовать API, потому что он снимает бремя сохранения файла на диск, что не так сложно с сериализацией? Я упустил суть?
Ответы 4
Было бы так сложно поместить все настройки по умолчанию в один класс, чтобы они не засоряли ваш код?
Я использовал общая конфигурация в последних проектах. Я изучил API настроек Java, но мне нравится гибкость проекта Commons. И вам не нужно указывать значения по умолчанию!
Здесь вы смешиваете несколько концепций. Значение по умолчанию, указанное в коде, должно соответствовать локальной ситуации как «разумное значение по умолчанию». Если вы хотите иметь настройки по умолчанию для всего приложения, вам нужен поставщик предпочтений, который позволяет подключать как настройки по умолчанию, так и наложенные пользовательские настройки. То, что само по себе может быть стоящим проектом.
Да, и «разумные значения по умолчанию» - отличный способ избежать настройки, когда в этом нет необходимости, но позволить пользователю или упаковщику предоставить лучшие значения, когда это необходимо.
@comment, думаю, я понял.
Под «местной ситуацией» я подразумеваю в контексте кода. Для вашего графического интерфейса вам нужно значение для отображения, которое представляет все, что использует поток. Поэтому я бы использовал что-то вроде Worker.DEFAULT_TIMEOUT. Ваш рабочий будет внутренне использовать то же значение, что и значение по умолчанию. Таким образом, вы получаете настроенное значение или значение по умолчанию для рабочего, когда настраиваете его поведение.
Вы можете поместить значения по умолчанию в файл .preferences, который вы объединяете в свой файл .jar (или в специализированный класс или интерфейс с константами).
Я использую его для таких вещей, как положение / размер окон, запоминание папки по умолчанию для выбора файлов, последних открытых файлов и других мелочей. Я могу придумать несколько интересных вещей, которые вы получите «бесплатно» с помощью API настроек:
- делать что-то рекомендованным ОС способом; ОС может не позволять вам записывать «файлы настроек» в папку вашего приложения, и пользователи не любят, когда их спрашивают, где на диске они хотят сохранить настройки, и вы не хотите реализовывать свою собственную логику для каждой платформы.
- ваши данные сохраняются для каждого пользователя ОС отдельно
- способ сохранить данные пользователя, даже если ваше приложение было удалено (или во время обновления)
- не нужна база данных или доступ к файловой системе
Кроме того, я не люблю сериализацию и не рекомендую ее для этого. Сериализация означает, что вы должны проявлять осторожность при изменении классов в новых версиях приложения.
тогда вы можете захотеть получить полный контроль над тем, как предпочтения должны соответствовать желаемому хранилищу, реализовав AbstractPreferences. Здесь вы можете увидеть реализацию на основе Linux:
http://www.docjar.com/html/api/java/util/prefs/FilePreferencesImpl.java.html
Удачи!