封装Java首选项API

发布于 07-07 18:40 字数 221 浏览 10 评论 0原文

我曾经为我的应用程序有一个自定义首选项类。 对于我的下一个爱好项目,我想切换到首选项 API。 但是 put 和 get 函数需要默认值,我不想将默认值传播到整个源文件。 尽管我的项目很小,但我无法想象更改整个源代码的默认值。 大家都是怎么使用api的呢? 我正在考虑将首选项 api 包装在另一个类中,但是使用 API 的意义何在,因为它只会消除将文件保存到磁盘的负担,而使用序列化并不那么困难? 我错过重点了吗?

I used to have a custom preferences class for my applications. For my next hobby project i wanted to switch to the Preferences API. But the put and get functions require a default value and i do not want to spread default values all over the source files. Even though my project is small i can not imagine changing default values all over the source code. How do you guys use the api? I am thinking of wrapping the preferences api in another class but then what is the point of using the API because it only takes away the burden of saving the file to disk, which isn't that hard using serialization? Am i missing the point?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

回眸一笑2024-07-14 18:40:21

您在这里混合了一些概念。 代码中给出的默认值应针对当地情况作为“合理的默认值”。 如果您想拥有应用程序范围的默认设置,那么您需要一个首选项提供程序,它允许您挂钩默认首选项和覆盖的用户首选项。 这本身就是一个有价值的项目。

哦,“合理的默认值”是避免不必要配置的好方法,但允许用户或打包者在需要时提供更好的值。

@评论,我想我明白了。

我所说的“本地情况”是指在代码的上下文中。 对于您的 GUI,您需要一个表示线程正在使用的显示值。 因此我会使用类似 Worker.DEFAULT_TIMEOUT 的东西。 您的工作人员将在内部使用与默认值相同的值。 这样,当您设置工作器的行为时,您就可以检索配置的值或工作器的默认值。

You're mixing a few concepts here. The default given in the code should be specific to the local situation as a 'reasonable default'. If you want to have application-wide defaults, then you need a preference-provider that allows you to hook in both the default preferences and an overlaid user-preferences. Something that may be a worthwhile project in itself.

Oh, and "reasonable defaults" is a great way to avoid configuration when it's not necessary but allow the user or packager to provide better values when needed.

@comment, I think I understand.

By 'local situation' I mean in the context of the code. For your GUI, you need a value for display that represents whatever the thread is using. Therefore I'd use something like Worker.DEFAULT_TIMEOUT. Your worker would use the same value internally as the default. That way you are retrieving the configured value or the worker's default when you are setting the worker's behavior.

舂唻埖巳落2024-07-14 18:40:21

那么您可能希望通过实现 AbstractPreferences 来完全控制 Preferences 应如何遵循您所需的存储。 您可以在此处查看基于 Linux 的实现:

http:// www.docjar.com/html/api/java/util/prefs/FilePreferencesImpl.java.html

祝你好运!

then you might want to take full control over how Preferences should follow your desired storage by implementing AbstractPreferences. You can see a linux based implementation here:

http://www.docjar.com/html/api/java/util/prefs/FilePreferencesImpl.java.html

Good luck!

挽梦忆笙歌2024-07-14 18:40:21

将所有默认值都放在一个类中以便它们不会乱七八糟地乱七八糟你的代码会这么困难吗?

我在最近的项目中使用了 commons 配置。 我研究了 Java Preferences API,但我喜欢 Commons 项目的灵活性。 而且您不必指定默认值!

Would it be so hard to stick all your defaults in a single class so that they weren't littering your code?

I've used commons configuration in recent projects. I've looked into the Java Preferences API but I like the flexibility of the Commons project. And you don't have to specify default values!

熊抱啵儿2024-07-14 18:40:21

您可以将默认值放入 .preferences 文件中,并将其捆绑在 .jar 文件中(或在带有常量的专用类或接口中)。

我用它来处理诸如窗口位置/大小、记住选择文件的默认文件夹、上次打开的文件等琐事。 我可以想到一些有趣的事情,你可以通过偏好API“免费”获得:

  • 以操作系统推荐的方式做事; 操作系统可能不允许您在应用程序文件夹中写入“设置文件”,并且用户不喜欢被询问他们想要将设置保存在磁盘上的哪个位置,并且您不希望为
  • 您的数据的 每个平台实现自定义逻辑为每个操作系统用户单独保存
  • 一种即使您的应用程序被卸载(或在升级过程中)也可以保留用户数据的方法
  • 不需要数据库或访问文件系统

此外,我不喜欢序列化,也不推荐它这。 序列化意味着在应用程序的新版本中更改类时必须小心。

You can put default values in .preferences file which you bundle in your .jar file (or in specialized class or interface with constants).

I use it for things like window positions/sizes, remembering default folder for choosing files, last opened files and such trivia. I can think of some interesting things you get "for free" with preferences API:

  • doing things in OS-recommended way; OS might not allow you to write "settings files" in your app folder, and users don't like to be asked where on disk they want to save settings, and you don't want to implement your custom logic for every platform
  • your data is saved for each OS user separately
  • a way to keep user data even if your application is uninstalled (or during an upgrade)
  • don't need database or access to file system

Also, I don't like serialization and don't recommend it for this. Serialization means you have to take care when changing your classes in new versions of your application.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文