问题：
一开始，H公司的程序员选择了MSXML作为XML解析工具。后来终于发现了MSXML的愚蠢(注：本文不讨论为什么MSXML是愚蠢的)，于是决定把MSXML换成libxml2。由于已经有大量的代码是直接基于MSXML开发的，因此这样的移植工作相当的劳民伤财。为了防止以后再发生这样的悲剧，H公司决定为XML解析器提供一个wrapper层，该层抽象出了一个与具体解析器无关的抽象XML Processing API，程序员使用这个API来完成XML解析，而不必关心底层的解析器到底是使用了MSXML还是libxml2，或者是Xerces-C++。这样，一旦以后需要更换XML解析器，比如从libxml2换成expat，只需要使用expat重新实现一下XML wrapper API即可，客户程序员不用在为移植他们的程序而伤脑筋，他们甚至不用再重新编译他们的代码。
目标：- 我希望解耦合XML Processing API和具体的实现。
- 我希望向客户程序员完全隐藏抽象接口的实现细节。
- 我希望对抽象接口的实现部分的修改不会对客户程序员有任何的影响，即客户的代码无须重新编译。
从目标来看，GoF的Bridge模式似乎是一个不二选择。