封装Java首选项API
我曾经为我的应用程序有一个自定义首选项类。 对于我的下一个爱好项目,我想切换到首选项 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 技术交流群。
发布评论
评论(4)
那么您可能希望通过实现 AbstractPreferences
来完全控制 Preferences 应如何遵循您所需的存储。 您可以在此处查看基于 Linux 的实现:
http:// www.docjar.com/html/api/java/util/prefs/FilePreferencesImpl.java.html
祝你好运!
将所有默认值都放在一个类中以便它们不会乱七八糟地乱七八糟你的代码会这么困难吗?
我在最近的项目中使用了 commons 配置。 我研究了 Java Preferences API,但我喜欢 Commons 项目的灵活性。 而且您不必指定默认值!
您可以将默认值放入 .preferences 文件中,并将其捆绑在 .jar 文件中(或在带有常量的专用类或接口中)。
我用它来处理诸如窗口位置/大小、记住选择文件的默认文件夹、上次打开的文件等琐事。 我可以想到一些有趣的事情,你可以通过偏好API“免费”获得:
- 以操作系统推荐的方式做事; 操作系统可能不允许您在应用程序文件夹中写入“设置文件”,并且用户不喜欢被询问他们想要将设置保存在磁盘上的哪个位置,并且您不希望为
- 您的数据的 每个平台实现自定义逻辑为每个操作系统用户单独保存
- 一种即使您的应用程序被卸载(或在升级过程中)也可以保留用户数据的方法
- 不需要数据库或访问文件系统
此外,我不喜欢序列化,也不推荐它这。 序列化意味着在应用程序的新版本中更改类时必须小心。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
您在这里混合了一些概念。 代码中给出的默认值应针对当地情况作为“合理的默认值”。 如果您想拥有应用程序范围的默认设置,那么您需要一个首选项提供程序,它允许您挂钩默认首选项和覆盖的用户首选项。 这本身就是一个有价值的项目。
哦,“合理的默认值”是避免不必要配置的好方法,但允许用户或打包者在需要时提供更好的值。
@评论,我想我明白了。
我所说的“本地情况”是指在代码的上下文中。 对于您的 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.