配置文件程序管理

     应用程序中一般都有各种可配置项，它们往往通过配置文件的形式存在于程序可执行目录、操作系统目录或者注册表中。开发过程中，由于需求的不断变化，配置文件的格式也跟着不断变化，与之对应的最难受的问题就是没有什么成就感的配置文件读写操作的变化。这对于需求稍微明确点的项目来说问题不大，至少很少会从根本上对配置文件的格式进行修改。然而，对于一个研究型的项目，大多数程序“从无到有”的过程来说，这种变化往往很频繁。如何合理地组织与配置文件（或者叫序列化和反序列化）相关的程序，以使程序比较灵活，修改起来比较容易，是一个很值得好好考虑的问题。

    配置文件一般分为两种，一种是与用户相关直接相关的配置，可以称为软配置，这样的文件在程序运行过程中可以随时接受用户的修改；而另一种是与外部环境相关的配置，一旦环境确定，配置文件基本就不变了，否则会导致程序运行不正确。很多软件都将这两种类型的配置合二为一。但对于追求用户友好性的程序，把它们区分出来单独对待还是有必要的。简单地说，程序运行的各种参数，如使用何种协议、端口号等可以作为一种与环境有关的配置，在程序运行过程中，这些配置不能改变，即使改变了也不应该去处理，除非用户重启。而对于界面风格等可配置项则可以作为用户可以随时修改并及时反映到应用程序的文件。

    软件做的越灵活，对用户越友好，其对应的可配置项就越多，在软件开发过程其变化频率就越高。并且配置文件的作用域往往具有全局性，很难将“由于配置项变化而引起的代码变化”局限到一个局部范围。用面向对象的说法就是很难“将这些变化封装到一起”，做到“单一职责原则”。其原因在于配置文件不同配置项之间可能根本就没有语义相关性，两个没有相关性的元素在代码中往往也是两个没有任何关系的类。

    有没有现成的什么方案，可以有效地解决这个问题，把“大量没有成就感的人力劳动”给解放出来，一直困扰着我。曾经尝试过统一对配置文件进行序列化和反序列化，将配置文件封装到一起传给各个需要配置的模块，然而配置文件的变化导致配置类的变化，配置类的变化导致所有用到该类的所有模块发生变化，最终以“听到要改配置项就想自杀”而宣告失败。也尝试过分散配置文件的使用，带来的问题更明显，修改一下格式要到处去找所有的比如“ReadFile"、”WriteFile“ 等操作，更是头疼。