现在不少应用采用插件系统，应用规定了若干接口，开发者可以使用这些接口编写插件，然后向应用系统注册插件，从软件设计的角度看，这就是可扩展对象模型，此处插件可以进行任意扩展，但使用插件的应用系统却保持不变，因此是片面的可扩展对象模型。此处片面一词并无贬义，只是根据需要来使用这种模型而已。
若这种可扩展模型中，连调用插件的应用主体都进行了扩展，则可称为全面可扩展对象模型。
实现一个可扩展对象模型是比较复杂的，涉及到模块功能的抽象思维和面向对象的编程思想，在此使用文件系统的对象模型来演示一番。
首先进行软件功能的抽象，文件系统的功能主要有
1。文件系统有文件和目录组成。每个文件和目录都用名称。
2。目录可以包含若干个子目录和文件，如此构成文件树状列表。
3。目录下可以新增和删除子目录或文件，可以修改目录名或文件名。
4。可以获得目录的所有子目录或文件列表，目录可以获得指定名称的子目录或文件。
5。文件可以读取或写入二进制数据，获得操作文件的流对象。
此外还有若干其他功能。
很显然，所有的文件系统都应当实现上述的基本功能，于是很容易设计出以下三个对象
XFileSystemBase 为文件系统的主体对象，或者顶级对象，用于支持整个文件系统模型的运行。
XDirectoryBase 抽象目录对象。
XFileBase 抽象文件对象。
这三个对象抽象定义了文件系统的通用功能，并构造了文件系统的对象模型，并实现了一些例程。
抽象文件系统对象模型建立以后，我们首先针对操作系统的文件系统进行扩展，主要使用了System.IO 名称空间下的模块，对XFileSystemBase , XDirectoryBase 和 XFileBase 都进行了扩展。从而产生了三个新的类型 StdFileSystem , StdDirectory 和 StdFile 。
想必有人会问，直接使用System.IO 名称空间不是很方便吗，为何多此一举？其实很多设计模式的使用，都是扩大了编写代码的初期投入，花了不少时间来构造对象模型，一旦模型建立起来，实现类似功能的软件模块就很容易了，而且避免代码的拷贝和重复。从长远看这是非常值得的。但设计模型需要使用合理，不要教条主义，根据当前需要和可预见的未来合理使用。
一些信息系统需要建立类似这种文件系统的功能，但是不是基于操作系统的标准文件系统的，而是基于数据库的。于是我们有从抽象文件系统派生出基于数据库的文件系统模型，在此实现了三个类型 DBFileSystem , DBDirectory 和 DBFile 。其中DBFileSystem中使用一个标准的数据库连接对象来获得原始数据。DBDirectory 和 DBFile 调用DBFileSystem 提供的内部方法来获得对象数据。
这样一个应用系统中，若使用 XFileSystemBase 访问文件系统，则可以根据需要将 XFileSystem 对象指向到 StdFileSystem 或 DBFileSystem , 如此应用系统既可以访问标准文件系统，也可以访问保存在数据库中的文件系统，两者可任意切换而不影响应用系统的其他功能。增强的软件的灵活性。
由于这个文件系统是全面可扩展的，因此可以实现基于WebService , 基于 ftp 等等的文件系统，而后应用系统就可以支持WebServer,FTP等的文件系统模型了。
本人推出的XDesignerLib图形设计器中间件中，花费了数万行代码用来构造可全面扩展的设计器文档对象模型，这种文档对象模型的扩展方式类似于这里的抽象文件系统，只是接口更加丰富而已。
这个抽象文件系统联想到虚拟技术，有时软件虚拟硬件或其他软件。比如虚拟光盘软件就根据保存在硬盘中的光盘镜像文件来虚拟一个光盘。虚拟磁盘软件则使用内存虚拟一个磁盘，可在频繁读写磁盘文件的时候可以倍增操作速度。微软的操作系统的底层定义了通用的文件系统接口，而应用软件可以实现这个通用文件系统接口来虚拟出各种光盘和硬盘。
同理，此处首先定义了文件系统的通用接口，然后StdFileSystem , DBFileSystem 通过实现这个通用接口来虚拟文件系统。
此处提供 抽象文件系统，标准文件系统和数据库文件系统的源代码和演示数据库，该代码未经严格测试。http://files.cnblogs.com/xdesigner/xfilesystem.rar .
袁永福 ( http://www.xdesigner.cn ) 2006-12-4