是“主要偏好”上课好主意？ [英] Is a "master preferences" class a good idea?
问题描述
我遇到了在这个过程中集中化设计的另一个暗示。该软件有一个公共API。该API可以自己在一个jar中提供。该API中的类可能引用pref管理类。所以，pref管理器必须进入API jar。
每个首选项都可能有一个默认值。在软件启动时，可以计算该默认值。该算法取决于偏好，因此倾向于驻留在使用代码附近。所以如果pref管理器需要提出一个默认值，它会调用相关的类。
但是现在，pref管理器已经成为一个章鱼类各种类进入API jar不应该在那里。如果没有，则使用API jar的程序很快就会遇到ClassDef异常。如果是这样，那么API jar现在变得blo肿了，因为每个其他类都可能引用其他类。
一般来说，其他Java程序员可以管理他们的偏好一个集中的类？
将静态pref管理类作为公共API的一部分分发是否有意义？
应该是那个pref管理器是确定默认值的代码的保持者？
嗯，我认为你的答案第一个问题是是和否。
首选项通常作为一个集中式的类来处理，在这个意义上，该类是许多类的该项目。试图做更接近调用代码的意思是，如果相同的偏好在以后在其他地方有用，你就会遇到麻烦。根据我的经验，尝试将偏好设置为太近也会导致非常不协调的处理。
据说，通常最好使用多个偏好类或偏好设置，每个都支持一个模块或子模块。如果您查看架构的主要组件，您通常会发现该组偏好可以在逻辑上进行分区。这减少了每个偏好类的混乱。更重要的是，它将允许您将程序分成多个罐子。现在，默认值计算器可以放置在模块中，但仍然在一个全局足够的区域。
我还建议不要将偏好设置直接设置为静态方法，而是使用一些getInstance（）操作来获取首选项管理的共享实例，然后在它。根据您的语义，您可能希望将该对象锁定一段时间（例如，当用户在UI中编辑首选项时），如果您具有实际对象，这将更容易。
对于其他问题，我会说您的公共API应该有一种让用户更改偏好设置的方式，但只有当您能够足够的记录这些更改的结果可能是什么。
如果您使用单一API函数获取参考管理器，您可以向用户提供提供自己的默认值计算器的可能性。首选的偏好管理器先要求这个计算器，然后再使用默认设置。
I have a class that manages user preferences for a large software project. Any class in the project that may need to set or retrieve a user preference from a persistent store is to call the static methods on this class. This centralized management allows the preferences to be completely wiped programmatically - which would be impossible if each pref was handled close to its use code, sprinkled throughout the project.
I ran into another implication of the centralization design in the course of this. The software has a public API. That API can be provided by itself in a jar. Classes in that API might refer to the pref management class. So, the pref manager has to go in the API jar.
Each preference might have a default value. Upon software startup, that default might be computed. The algorithm depends on the preference, and thus tends to reside near the use code. So if the pref manager needs to come up with a default, it calls the class in question.
But now that pref manager has become an "octopus class", sucking in all sorts of classes into the API jar that shouldn't be there. If it doesn't, then programs using the API jar quickly run into ClassDef exceptions. If it does, then the API jar is now bloated, as each of those other classes may refer to still others.
In general, do other Java programmers manage their preferences with a centralized class?
Does it make sense to distribute that static pref management class as part of a public API?
Should that pref manager be the keeper of the code for determining defaults?
IMHO, I think that the answer to your first question is "yes" and "no".
Preferences are commonly handled as a centralized class, in the sense that the class is a "sink" for many classes in the project. Trying to do it closer to the calling code means that if the same preference is later useful elsewhere, you are in trouble. In my experience, trying to put the preferences "too close" also results in a very inconsistent handling.
That being said, it is often preferable to use multiple preference classes or "preference set", each supporting a module or submodule. If you look at the main components of your architecture, you will often find that the set of preferences can be logically partitioned. This reduces the mess in each preference class. More importantly, it will allow you to split your program into multiple jars in the future. Now, the "default value" calculators can be placed in the module but still in a global enough area.
I would also suggest not setting preferences directly as static methods, but rather using some getInstance() like operation to obtain a shared instance of the preferences manage, and then operating on it. Depending on your semantics, you may want to lock that object for a while (e.g., while the user is editing preferences in a UI) and this is easier if you have an actual object.
For your other questions, I would say that your public API should have a way of letting users change preferences, but only if you can document well enough what the results of these changes could be.
If you use a single API function to get the "reference manager", you can give users the possibility of providing their own "default values calculator". The preference manager will ask this calculator first before resorting to the one you have provided by default.
这篇关于是“主要偏好”上课好主意？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
