“大师级偏好”课程是个好主意吗?

我想你第一个问题的答案是“是”和“不是”。

也就是说,通常最好使用多个偏好类或“偏好集”,每个偏好类或“偏好集”支持一个模块或子模块。如果您查看体系结构的主要组件,通常会发现首选项集可以进行逻辑分区。这减少了每个首选项类中的混乱。更重要的是,它将允许您在将来将程序拆分为多个JAR。现在,“默认值”计算器可以放在模块中,但仍然可以放在一个足够全局的区域中。

我还建议不要直接将首选项设置为静态方法,而是使用一些类似getInstance()的操作来获取preferences manage的共享实例,然后对其进行操作。根据您的语义,您可能希望锁定该对象一段时间(例如,当用户在UI中编辑首选项时),如果您有一个实际的对象,这会更容易。

对于您的其他问题,我认为您的公共API应该有一种允许用户更改首选项的方法,但前提是您能够充分记录这些更改的结果。

如果您使用单个API函数来获取“参考管理器”,则可以为用户提供自己的“默认值计算器”。首选项管理器将首先询问此计算器,然后再使用默认情况下您提供的计算器。

你不能用一种非常通用的方式来处理偏好吗?然后,您只需使用首选项管理器来处理持久性。因此,从一个类中,您只需要对preference manager PreferenceManager.setPreference(key,value)说,它并不关心它在数据语义方面保存了什么。

还是我把这个简化得太多了?

类似于.NET提供程序模式的东西?

你可能想看看科科的 NSUserDefaults

它最后检查的绝对位置称为“注册域”,这基本上是硬编码默认值应该去的地方。因此,在我的代码中的任何时候,我都可以将首选项写入注册域 NSUserDefaults

因此,在您的例子中,您可以为类提供一种方法,以便在键访问(可能)用户定义的值之前为其设置默认值。preferences类不必知道它所服务的类的任何信息。

正如其他人所建议的,如果你需要更复杂的东西,你可以设置一个 DefaultValueProvider 回调对象而不是直接值。

要真正解决实际问题——感觉您希望将首选项(以及默认值的计算)与使用它们的代码放在一起是有意义的。

您的全局集合可以做一些事情,比如迭代每一组首选项并将其重置为默认值,但是您的首选项本身仍然是本地定义和维护的,这样它就不会蔓延到代码的其他部分。

我想这可以通过让主“preference”类实例化所有其他类来解决,然后任何代码段都可以通过静态getter从中心类检索其本地preference对象。

这似乎很像一些伐木工人的工作方式。有一个用于维护日志级别、输出流等的中央机制,但每个类都有自己的“log”方法实例并记录到它。

我希望这更符合目标。哦,我也同意公认的答案,永远不要把你所有的方法都公开,总是使用getter——总有一天你会很高兴你这么做的。

java.util.prefs.* )API使用带有 Class<?> 要创建的参数 Preferences 实例。这样,API可以将属于同一个包的不同类的首选项存储在单个文件中。