0

我正在设计一个复杂的配置类作为 API 设计的一部分。配置类大致看起来像这样..（我忽略了泛型/访问修饰符等）

class Configuration {
    One obj1;
    Two obj2;
}

class One {
      List<Double> values;
}

class Two {
      double value;
      Map<String, Double> data;
}

这就是我想要完成的：

  • 我希望用户能够在第一时间轻松创建此配置类并提交到服务器。
  • 然后他们可以更改此类的任何部分并将更新的配置发送到服务器。

使用和避免哪些设计模式？

使此类不可变并使用构建器模式会更好吗？或者只是在配置类上提供各种修改方法，这样他们就可以就地修改相同的配置类（在所有级别），而不必为每次更新创建一个新的配置类。我认为 Builder 模式仅适用于不可变类。

问题：

  • 有没有办法在这种类型的场景中利用 Builder 模式？
  • 还是像我上面提到的那样在 Configuration 类上提供 mutator 方法更好？
  • 还是有其他更好的模式可用？
4

1 回答 1

0

我认为您应该使用原型模式：在您的代码中，您可以添加包含所有类型配置的映射，该映射将有一个名为“currentConfiguration”的键，值将是应该加载的配置。地图还可以包含可以存储在地图中的其他配置，并且可以在需要时替换当前配置。从地图中获取配置后，您只需克隆配置对象，用户就可以做任何他喜欢的事情。更改后，他可以使用特定名称将配置保存在地图中。因此用户可以获得与他需要的非常接近的配置对象并相应地对其进行配置。代码应如下所示：`public class CloudRepository {

private Map<String, Configuration> rep;

public CloudRepository(Configuration current){
    rep = new HashMap<String, Configuration>();
    rep.put("current", current);
}

public Configuration getConfiguration(String string){
    return (Configuration) rep.get(string).clone();
}

public void addConfiguration(String name, Configuration conf){
    rep.put(name, conf);
}

public void replaceCurrentConfiguration(Configuration conf){
    rep.put("current", conf);
}

}

您还可以编写更多代码来处理配置的历史记录。你也可以考虑让这个类单例

于 2013-02-18T12:07:14.967 回答