本文是小编为大家收集整理的关于一次性加载配置属性的设计模式？的处理/解决方法，可以参考本文帮助大家快速定位并解决问题，中文翻译不准确的可切换到English标签页查看源文。
问题描述
我经常面临在内存中存储从文件系统上的文件加载的一些(可能很复杂)配置设置的问题.但是，我想知道是否有比我一直在使用的更好的方法来构建解决这个问题的模式.
基本上，我目前的解决方案包括三个步骤.
构建一个单例.由于数据是持久的并且保证不会在应用程序的运行时发生变化，因此应该只需要一个对象实例.
当第一次请求对象时，创建对象并从文件中读取.
使用 getter 公开数据.
这使得我的很多代码看起来像这样:MyConfiguration.getInstance().getWeightOfBomb()，我觉得这很奇怪.
有没有更好的方法以更语义化的方式处理这个问题?
推荐答案
依赖注入.您不一定必须使用像 Spring 或 Guice 但您确实希望避免在代码中乱扔单例.您仍然可以在实现中使用单例，但是您的其余代码没有理由需要知道它是单例.在单元测试和重构时，单例是巨大的痛苦.让您的代码引用一个接口.例如，
interface MyConfig {
double getWeightOfBomb();
}
class SomeClass {
private MyConfig myConfig;
public void doSomething() {
myConfig.getWeightOfBomb();
}
}
class MyConfigImpl implements MyConfig {
public double getWeightOfBomb() {
return MyConfiguration.getInstance().getWeightOfBomb();
}
}
如果您使用 DI 框架，只需设置您的类以注入您的 MyConfig 实现.如果您不这样做，那么仍然具有所有好处的最懒惰的方法是执行以下操作:
class SomeClass {
private MyConfig myConfig = new MyConfigImpl();
}
这真的取决于你.重要的是，当您后来意识到您需要改变行为和/或进行单元测试时，您可以逐个实例替换 myConfig.
问题描述
I'm often faced with the problem of storing, in memory, a few (possibly complex) configuration settings loaded from files on the filesystem. I'm wondering if there's a better way to architect a pattern to this problem, however, than what I've been using.
Essentially, my current solution involves three steps.
Build a singleton. Since data is persistent and guaranteed not to change through the runtime of the application, only one object instance should ever be needed.
When the first request for the object is made, create the object and read in from a file.
Expose data with getters.
This has the effect that a lot of my code looks like this: MyConfiguration.getInstance().getWeightOfBomb(), which looks rather odd to me.
Is there a better way to handle this in a more semantic fashion?
推荐答案
Dependency Injection. You don't necessarily have to use a DI framework like Spring or Guice but you really want to avoid littering your code with singletons. You can still use a singleton in the implementation, but there is no reason the rest of your code needs to know that it is a singleton. Singletons are huge pain when unit testing and refactoring. Let your code reference an interface instead. e.g.,
interface MyConfig {
double getWeightOfBomb();
}
class SomeClass {
private MyConfig myConfig;
public void doSomething() {
myConfig.getWeightOfBomb();
}
}
class MyConfigImpl implements MyConfig {
public double getWeightOfBomb() {
return MyConfiguration.getInstance().getWeightOfBomb();
}
}
If you use a DI framework, just setup you classes to have your MyConfig implementation injected. If you don't, then the laziest approach that still has all the benefits is to do something like:
class SomeClass {
private MyConfig myConfig = new MyConfigImpl();
}
Really it's up to you. The important thing is that you can replace myConfig on a per instance basis when you later realize that you need the behavior to vary and/or for unit testing.
更多相关问答
联系站长