配置设计答案

【问题标题】：Configuration Design配置设计
【发布时间】：2016-05-17 07:31:17
【问题描述】：

我对如何设计配置感到困惑。该软件具有因客户而异的配置文件。所以对于customerA，配置文件可能有参数 A 和参数 B。对于customerB，配置文件将包含parametarA、parametarB 和parametarC。因此，并非所有控制软件行为的参数都包含在所有配置文件中。此外，这些参数并非都是简单类型，如整数、字符串和双精度数，即它们本身可以是结构女巫还包含可选成员。假设我有以下 CustomerC 参数：int 类型的 param1，structA 类型的 param2， structB 类型的参数 3。

   structA
   {
      int param1;
      boost::optional<double> param2;
   };

   struct B
   {
     optional<int> param1;
     optional<int> param2;
   };

所以我有两个选择： -第一个选项将参数存储为映射中的键/值。对参数的访问是使用字符串名称和一个必须知道接入点的参数类型才能将其转换为适当的类型。在我存储的地图中只有客户所需的参数。在检索参数之前，必须检查参数是否存在于地图中，并使用它。

-第二个选项是拥有一个包含所有客户的所有可选成员的大型 conf 类，并且必须检查是否 optional 参数在使用前被初始化，所以这和 option1 一样。好处是不需要知道参数的类型在访问它之前，因为参数在编译时是已知的。坏事是我有一个包含所有参数的大类顾客。这有点奇怪。但除此之外，这个选项 2 看起来不错。

   class Conf
   {
      optional<int> Param1;
      optional<StructA> Param2;
      optional<StructB> Param3;
      optional<double>  Param4;
      optional<int>     Param5;
      //all software params for all customers
   };

当我可以在课堂上时，为什么还要在地图中存储参数？我能想到的一个原因是因为在地图中您可以在运行时添加参数如果你想不重新编译，但如果你要添加控制软件某些方面的新参数，你必须包括应用程序逻辑中的参数，因此您需要重新编译的任何地方。我在网上搜索，似乎很流行存储配置在地图中。所以我在这里遗漏了一些东西

【问题讨论】：

您只需要重新编译使用带有map 的新值的新代码，并且您也不会破坏二进制兼容性。
无论如何我都会重新编译任何东西。所以这不是必需的。
看起来像是依赖注入的案例 - 现在没有时间详细说明。
我对另一个stackoverflow问题的回答并没有完全回答你的问题，但它可能会提供一些启发：stackoverflow.com/questions/31330782/…

标签： c++ design-patterns configuration

【解决方案1】：

正如其他人所提到的，这是研究依赖注入和/或面向方面编程 (AOP) 的好地方。

关于选项 2：将所有这些不相关的客户信息存储在一个地方令人担忧。

至于选项 1：我不确定我是否理解您对不利方面的陈述。是的，您必须知道某种键名，但即使您将每个用户的信息硬编码在一个公共类中也是如此，不是吗？确实，您并没有真正从修改此地图的能力中获得太多 - 这可能是一个小缺点 - 但我认为你并没有真正牺牲任何东西。

总体而言，我认为选项 1 是一个不错的选择，并且您似乎对如何实施它有一个很好的想法。你认为你究竟“缺少”了什么？

无论您是否将它用于此项目，请查看依赖注入。 它旨在成为分离程序各个方面（例如单独的配置选项）的最佳方式。其他不错的用例是身份验证、日志记录、UI 主题...不胜枚举。

【讨论】：