Configuration Design

Question

I have dilemma how to design the configuration. The software has configuration files that vary by customer. So for customerA the config file may have parametarA and parametarB. and for customerB the config file will have parametarA, parametarB and parametarC. So not of all the parameters that control software behavior are included in all configuration files. Further, this parameters are not all simple types like ints, string and doubles, i.e they can be themselves structures witch contain also optional members. So say I have the following parameters for CustomerC : param1 of type int, param2 of type structA, param3 of type structB.

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

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

So I have two options : -first option to store the parametars as key/values in map. access to parametars is with string name , and one have to know the type of the parametar at access point to cast it to the adequate type. in the map I am storing only the required params for the customer. one have to check whether the parametar exists in the map before retrieving it, and using it.

-second option is to have one big conf class which contains all optional memebers for all customeers, and one have to check whether the optional parametar is initialized before using it, so this is same as option1. The good thing is one doesnot need to know the type of the parametar before accessing it, because the parametar is known at compile time. Bad thing is that I have one big class that contains parameters for all customers. This is a little strange. But besides that this option2 looks good.

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

Also why to store parameters in map when I can in class ? One reason that I can thinkof is because in map you can add parameters at runtime if you want without recompiling, but if you are gonna add new parameter which controls some aspect of the software you have to include the parametar in the application logic, so anywhere you need to recompile. I was searching the internet and it seems popular to store the configuration in a map. So I am missing something here

You only have to recompile the new code that uses the new values with a `map` and you don't break binary compatibility either. — Galik, May 17 '16 at 07:39
Looks like a case for dependency injection - don't have time right now to go into details. — Frank Puffer, May 17 '16 at 08:30
My answer to another stackoverflow question does not fully answer your question, but it might provide some inspiration: http://stackoverflow.com/questions/31330782/how-to-handle-large-number-of-configuration-parameters-across-a-program-conceptu/31351052#31351052 — Ciaran McHale, May 23 '16 at 20:53

score 0 · Answer 1 · answered May 20 '16 at 18:11

As someone else mentioned, this is a great place to look into dependency injection and/or Aspect Oriented Programming (AOP).

Regarding Option 2: it's worrisome to have all these unrelated customers' information stored in one place.

As far as Option 1: I'm not sure that I understand your statement of the downside. Yes, you have to know some kind of key name, but that is true even if you hardcode every user's information in one public class, isn't it? It is true that you don't really gain much from the ability to modify this map -- it's probably a minor downside -- but I don't think you really sacrifice anything.

Overall, I think option 1 is a good choice and it seems like you have a good idea of how to implement it. What do you think you are "missing" exactly?

Whether or not you use it for this project, check out dependency injection. It is designed to be the best way to separate aspects of your program such as individual configuration options. Other nice use cases are authentication, logging, UI theming... the list goes on.

Configuration Design

1 Answers1