当你使用任何编程语言编写一个应用程序的时候，在你编写的应用程序中，总会存在某些代码片段，它们除了能作用于当前编写的应用程序外，还能用于其他的应用程序上。
软件行业从诞生的第一天开始，主要关注的问题就是“代码重用”。所以程序员一直被教导，去设计“可重用的代码”，例如：
- 用函数（Functions）去替换程序中重复出现的代码块
- 用库（Libraries）将常用的函数打包起来，供程序员调用
- 面向对象编程（OOP）将代码和数据捆绑在对象（Objects）中，供程序员引用
- 对象库（Libraries of Object）
- 框架（Frameworks，亦或平台）
很多软件开发工程师从没到达过框架的层次，所以他们不懂框架是什么，也不知道它和库有什么不同。
库仅仅只是存放代码，函数，对象，可能还有全局变量（但很少）的容器。而框架其本身就是一个应用程序，它是一个结构，可以用来为开发者创建程序的基础部分，这样，开发者就不必一遍又一遍的，为他的每一个程序重复创建。
想象一下你是摩天写字楼的建筑商。每一栋建筑都需要一定的服务。你需要停车场，电力，给水排，电梯，空调，供暖，你还可以继续列举。再假想一下，你有一个停车场“模块”，你修改一下“停车数量”参数，然后“扑通”一声把它丢在地上，这栋写字楼的停车场就建好了。继续想象一下，你用相同的方式将剩下的电力，给水排等服务都建好了。全套繁重的写字楼设计和建筑工作就这样完成了。更进一步来讲，想象你有全套的摩天写字楼结构，你只要简单的修改一下“停车数量”，高度，宽度，建筑的层数，电力系统的安培数，电梯的个数，电梯的高度，等等。你瞬间就有了一栋高层建筑，可以开始准备招商了。
这就是框架（Framework），但要以编程的角度。
有成吨的“服务”可供你的应用程序使用的话，那是再好不过了。这些服务就是那些“模块”，当你需要它的时候就创建它，当你用完它之后就拆掉它。这当然是可行的，这也是许多程序员做事情的方式，然而，这种方式需要手动的地方非常多。
我们假定某个开发者需要一个服务，比如将所有的系统错误记录下来。这种功能最典型的实现方式是用类，这意味着，你需要用这个类创建（实例化）一个对象，做完工作后，再将它卸载掉。或者，你可以让框架帮忙负责创建和卸载。你只需要调用框架的一个叫 “LogInit” 的方法，传递一个路径参数，指示你想把这个错误保存在什么地方。然后任何时候，系统发生错误，调用 “Log” 方法，传递系统的错误信息参数，系统错误就被记录下来。框架负责初始化这个 Log 类，存储路径信息，如果路径不存在则创建这个路径，当框架关闭时，卸载这个 Log 类。
再举一个稍微复杂一点的实际应用中的例子：为窗体装载控件类。我使用一个绑定窗体，我有这个窗体的类，同时也有组合框的类，文本框的类等等。组合框的类“懂得”如何处理“不在列表中”事件。如果我预先指定一个列表窗体，组合框的“不在列表中”事件会告诉用户他输入的数据不在列表中，是否想将其添加进去。如果用户说是的，类就以模式的方式打开指定的窗体。通过这个窗体，用户可以添加新的数据项进来。当用户关闭列表窗体后，组合框的类重新查询数据源，在列表窗体中新添加的数据项就可供选择了。
窗体类“懂得”如何去扫描窗体寻找放置其上的组合框控件。如果找到，框架会为每一个组合框都创建一个组合框类的实例。开发者只需要在窗体里面设置好代码，创建窗体类。窗体类会自动的去扫描和加载控件。当初始化完成，（在窗体类的 Init() 这一行之后），开发者可以为组合框指定相关的列表窗体。
所有这些功能都是框架要做的事情。对象类知道如何做事情。框架会记录对象的加载和卸载，在可能的时候自动清除掉对象。各种功能各司其职，因为框架会让这一切确保发生。
译者的话：
这篇文章主要介绍什么是框架以及与库的区别。用摩天写字楼的建设做类比也足够形象。
文中举的第二个例子，相当于我们谈论的控件子类化。将组合框的“不在列表中”事件的处理代码，从其所在窗体转移到组合框的子类中。组合框的子类由窗体的子类负责实例化。
关于该例子，后文中将会放出源码示例供大家参考。
通过子类化，你可以为 Access 的一些对象添加不存在的功能。子类化也许可以作为 VBA 的一个单独的话题拿出来讨论。
P.S.
我估计 Colby 的文章写于 2007 版 Access 出来之前，因为这之后，组合框的属性中就多了一条“列表编辑窗体”属性，开发者可以在此处直接指定一个窗体去负责处理不在列表中的事件发生时使用哪个窗体去编辑列表。