我有一个管理大型软件项目的用户首选项的类。项目中可能需要从持久存储中设置或检索用户首选项的任何类都将调用此类的静态方法。这种集中管理允许以编程方式完全删除首选项 - 如果每个首选项都在接近其使用代码的地方处理，散布在整个项目中，这是不可能的。
我在这个过程中遇到了中心化设计的另一个含义。该软件有一个公共(public) API。该 API 可以在 jar 中自行提供。该 API 中的类可能引用 pref 管理类。因此，pref 管理器必须放在 API jar 中。
每个首选项都可能有一个默认值。在软件启动时，可能会计算该默认值。该算法取决于偏好，因此倾向于驻留在使用代码附近。因此，如果 pref 管理器需要提供默认值，它会调用相关类。
但现在 pref 管理器已经变成了一个“ Octopus 类”，将各种不应该存在的类吸入 API jar 中。如果没有，那么使用 API jar 的程序很快就会遇到 ClassDef 异常。如果是这样，那么 API jar 现在就膨胀了，因为每个其他类都可能引用其他类。
一般来说，其他 Java 程序员是否使用集中式类来管理他们的偏好？
将静态 pref 管理类作为公共(public) API 的一部分分发是否有意义？
pref 管理者是否应该负责确定默认值的代码？
最佳答案
恕我直言，我认为您第一个问题的答案是"is"和“否”。
首选项通常作为集中式处理，因为该类是项目中许多类的“接收器”。尝试将其靠近调用代码意味着如果相同的首选项稍后在其他地方有用，那么您就有麻烦了。根据我的经验，尝试将首选项“靠得太近”也会导致处理非常不一致。
也就是说，通常最好使用多个首选项类或“首选项集”，每个首选项类或“首选项集”都支持一个模块或子模块。如果您查看架构的主要组件，您通常会发现首选项集可以在逻辑上进行分区。这减少了每个偏好类别中的困惑。更重要的是，它将允许您在将来将您的程序拆分到多个 jar 中。现在，“默认值”计算器可以放置在模块中，但仍处于足够全局的区域中。
我还建议不要直接将首选项设置为静态方法，而是使用一些类似于 getInstance() 的操作来获取首选项管理的共享实例，然后对其进行操作。根据您的语义，您可能希望锁定该对象一段时间(例如，当用户正在 UI 中编辑首选项时)，如果您有一个实际对象，这会更容易。
对于您的其他问题，我会说您的公共(public) API 应该有一种让用户更改首选项的方法，但前提是您可以足够好地记录这些更改的结果。
如果您使用单个 API 函数来获取“引用管理器”，则可以为用户提供提供他们自己的“默认值计算器”的可能性。偏好管理器会先询问此计算器，然后再使用您默认提供的计算器。
关于java - "master preferences"类是个好主意吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/592960/