"主人偏好"课是一个好主意吗？

我有一个类来管理大型软件项目的用户首选项.项目中可能需要从持久性存储设置或检索用户首选项的任何类都是在此类上调用静态方法.这种集中管理允许以编程方式完全擦除首选项 - 如果每个pref都是在接近其使用代码的情况下处理的话,这将是不可能的.

在此过程中,我遇到了集中化设计的另一个含义.该软件具有公共API.该API可以在jar中自行提供.该API中的类可能引用pref管理类.因此,pref管理器必须进入API jar.

每个首选项可能都有一个默认值.软件启动时,可能会计算该默认值.该算法取决于偏好,因此倾向于驻留在使用代码附近.因此,如果pref管理器需要提供默认值,它会调用相关的类.

但现在pref经理已成为一个"章鱼类",将各种类型的类吸入到不应该存在的API jar中.如果没有,那么使用API​​ jar的程序很快会遇到ClassDef异常.如果确实如此,则API jar现在变得臃肿,因为其他每个类都可能引用其他类.

通常,其他Java程序员是否使用集中式类来管理他们的首选项？

将静态pref管理类作为公共API的一部分进行分发是否有意义？

该pref经理是否应该成为确定默认值的代码的守护者？

恕我直言,我认为你的第一个问题的答案是"是"和"否".

首选项通常作为集中式类处理,因为类是项目中许多类的"接收器".尝试更接近调用代码意味着如果相同的首选项稍后在其他地方有用,则会遇到麻烦.根据我的经验,尝试将偏好设置为"太近"也会导致处理非常不一致.

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

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

对于您的其他问题,我会说您的公共API应该有一种让用户更改首选项的方法,但前提是您可以很好地记录这些更改的结果.

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