我在写一个DeskBand
Sample时，界面上出现的元素都是来自于配置信息，配置信息要从配置文件中来。目前是从注册表中来，但是，我们不能把它写死了。
还是那句话，封装是要封装变化，变化的东西是什么，是配置文件类型，XML，注册表，INI，数据库等等。数据格式，一般情况下变化不会太多。所以我们应该一个尽可能灵活的接口出来，即使某一天要从注册表换成XML，我们也能很从容应对。
我现在说一下我在LyraDeskBand中设计的读取配置文件信息的结构。
先看一下UML图。
说明：
1：IDeskBandConfig是一个抽象类（关于抽象类的定义，大家都知道吧），它其实也就是我们常说的接口，它定义了一系列操作配置文件的公共行为。
它肯定是抽象的，不依赖于具体的哪一种类型。
2：CDeskBandRegConfig是用于从注册表中读取信息的类，它实现了IDeskBandConfig接口。
3：CDeskBandXmlConfig是用于从XML文件中读取信息的类，这也实现了IDeskBandConfig接口。
4：像这样的具体的类还可能很多，有可能从INI文件中读，也有可能从数据库中读，这完全是有可能的。
5：CDeskBandEnumConfig这个类是用到枚举，每次得到的是都是一个IDeskBandConfig指针。这个类是一个单项实例类，首先你要告诉它，你到底想用什么类型的配置文件，是XML，还是注册表，但不管你用什么配置文件，它返出来的接口都是抽象的。
6：CDeskBandEnumConfig最主要的函数就是Next，如果没有下一个了或者出错，就返回FALSE，否则返回TRUE，使用的时候就可能用一个While循环来枚举所有的接口。
优点：
1：其实这种思路很简单，关键就在于你是否去尝试去做，这样有一个好处就是，不用在一个类里面包含几种不同的操作配置文件的方法，如果要添加一种配置文件，也是很容易的，再写一个派生类，实现各种方法。
2：如果还要增加新的行为，只需要在接口中添加新的纯虚函数就行了，在派生类中再去实现。
3：每个函数实现相当简单，简单就会导致BUG很少，也能保证可读性。CDeskBandEnumConfig的Next方法，实现只用了不到50行，这应该是相当简单的了。
缺点：
1：这种方法有一个很致命的缺点，就是如果某一天把配置文件的结构改了，那么IDeskBandConfig定义的接口就有可能不能使用，就会导致重新定义接口，这种方式是没有办法克服的，但话说回来，连配置文件结构都改动，这样的改动也算是很大的了。
2：还有的缺点，目前还没有想到，等待时间来考验它吧。
最后一点，我们设计的东西要尽可能地依赖于抽象，而不是具体的实现，具体的实现以后可能导致维护和扩展性不好。