Configuration File Program Management

Applications generally have various configuration items, which are usually stored in the executable directory, operating system directory, or registry in the form of configuration files. During the development process, the configuration file format is constantly changing due to the changing requirements. The most uncomfortable problem is that there is no sense of accomplishment in the configuration file read/write operations. This is not a problem for projects with a slightly clearer requirement. At least the configuration file format is rarely modified. However, for a research project, most programs are "from scratch", and such changes are often frequent. How to Reasonably organize the programs related to the configuration file (or serialization and deserialization) to make the program more flexible and easy to modify is a matter worth consideration.

Configuration files are generally divided into two types. One is the configuration directly related to the user, which can be called soft configuration. Such files can be modified at any time during the program running; the other is the configuration related to the external environment. Once the environment is determined, the configuration file will remain unchanged. Otherwise, the program runs incorrectly. Many software products combine these two types of configurations into one. However, it is necessary to separate user-friendly programs. Simply put, various program running parameters, such as the Protocol and port number, can be used as an environment-related configuration. During the program running, these configurations cannot be changed, it should not be processed even if it is changed, unless the user restarts. Configuration items such as the interface style can be modified by the user at any time and reflected to the application in a timely manner.

The more flexible the software is, the more user-friendly it is, the more configuration items it corresponds to, and the higher the frequency of change in the software development process. In addition, the scope of the configuration file is often global, and it is difficult to limit "code changes caused by configuration changes" to a local scope. It is difficult to "encapsulate these changes together" in the object-oriented way to achieve "single responsibility principle ". The reason is that there may be no Semantic Relevance between different configuration items in the configuration file. Two irrelevant elements are often two irrelevant classes in the code.

Is there any ready-made solution that can effectively solve this problem and free me of "a lot of human labor without a sense of accomplishment. I have tried to serialize and deserialize the configuration file in a unified manner, and encapsulate the configuration file together and send it to each module to be configured. However, changes in the configuration file lead to changes in the configuration class, changes in the configuration class lead to changes in all modules that use the class. In the end, the system fails to "commit suicide when you hear that you want to modify the configuration item. I have also tried to use the scattered configuration file, which brings more obvious problems. to modify the format, I need to search for all operations such as "readfile" and "writefile" everywhere, which is even more troublesome.