The uncertain framework (1)

今天开始在这里记录我在设计与开发uncertain框架时的一些想法。

我做这个框架的目的，是为了尝试一些潜在的，更为合理的程序架构的可能性。多年来我一直按照面向对象的思路去分析/设计系统，我越来越觉得有一些问题单纯按现有的面向对象的方法是无法圆满的解决的。

例如，任何一个图形化应用程序，不管是字处理，电子表格，图片处理，还是声音编辑，都有一个基本的 特性：如果用户关闭整个程序，而此时还有一些打开的文件没有保存，那么就需要对用户进行提示。所有的此类应用程序都会有类似的代码：
for each ( Document m in openned_docs ){
    if (m.isSaved()) {
        result = messageBox (....);
        if( result == YES) openSaveAsDialog;
        else if( result == NO) exitApplication;
        else if( result == CANCEL) return;
    }
}
我们知道，在用户退出程序时提示用户保存未保存过的文件，这是一个可以抽象出来的 特性，它与具体的应用无关，不管将来的程序是用来编辑什么类型的文件，这个特性总是存在的；但是，我们能不能创建一个对象（例如叫做ConfirmSave），来实现这个特性，以免在写不同应用程序的时候都要重复写类似的代码呢？很难做到。首先，如前面代码所示，我们需要遍历所有当前用户打开的文档以寻找未保存的文件，但此时我们无法确定将来的应用程序会用什么对象来保存这些文档。可能是一个Collection，也可能是List，或者自定义的非容器类的对象。其次，我们无法确定如何用一种普适的方法去判断一个文件是否未保存。按照面向对象的思路，我们应该定义一个类似IDocument的接口，并给它一个类似 boolean isSaved() 这样的方法。但是，在我们实现这个特性的时候，我们仅仅关注IDocument的这一个特性：能够判断是否保存，我们对IDocument其他可能的基本特性，比如保存到磁盘，从磁盘中读取，并不关心，并且在此时也无法确定。那么我们怎么能保证写出的IDocument能够抽象出所有文档都具备的基本特性，而不会在将来因为设计上的考虑不够而抛弃呢？无法保证。即使我们此时只给IDocument定义isSaved这一个方法，或者转而定义一个更加简单的接口ISaveCapable，以支持我们能够继续下去，我们还是会碰到第三个问题：如何调用一个对话框来提示用户是否需要保存呢？这个世界有无数种GUI类库/框架，对于C++有MFC、wxWindows、QT，对于Java有AWT、Swing、SWT，而我们需要创建的是一个与具体应用无关的特性，不依赖于实际的GUI框架，因此我们无法确定调用对话框这件事情在此是应该如何去做。如果我们继续抽象下去，定义一个IMessageBox, 或者IGuiFramework之类的接口，给它加上showMessageBox这样的方法，再在具体的GUI框架中创建类去实现这些接口，问题还是没有解决。此时我们可以确定这个对话框应该有三个按钮，分别代表是、否和取消，我们也可以确定这个对话框是模态的（modal），但我们此时还无法确定如何得到对话框上显示的提示。应用程序可能从注册表，ini/property文件，用户设置，字符串资源表，或者是源程序的预定义常数中得到某个字符串，谁知道呢？还有国际化问题。你的程序会支持多语言显示吗？

由此看来，我们的ConfirmSave暂时还无法写下去，在完成它之前，我们至少需要一个应用程序的文档模型，一个GUI框架，一个配置信息存取方案。抛开这些去实现一个独立的ConfirmSave，似乎是一件很无聊的事情。但我们确切地知道，在用户退出程序时提示用户保存未保存过的文件，确确实实是一个客观存在的特性，并且与具体应用程序关系不大，为什么我们就不能单独去实现它呢？将复杂系统划分为简单的、功能单一的模块，减少各个模块之间的耦合，不正是我们采用面向对象设计方法的初衷之一吗？

看来我们似乎确实遇到了面向对象的瓶颈：确实有一些东西，我们无法简单地用对象来实现，或者说，即使实现了，也由于对其他对象依赖程度过高，而导致可重用价值不大。在面向对象的哲学中我们碰到了一个两难的问题：如果将对象的划分粒度减小，功能尽可能做得单一（也即提高对象的内聚程度），会导致对象产生许多对其他对象的假设，引入过多的接口（或抽象类），从而导致对象间耦合度增加；如果将对象的划分粒度增大，让对象完成足够多的功能，又会使得对象变得庞大而难以维护，并且应用的范围也将受到局限。

当前有一些技术/模式试图解决这样的问题。例如 AOP，例如 IoC。对此我也有一些想法，我试图通过uncertain这个框架，来探寻这些想法的可行性。今天时间有限，先写到这里。