为什么要讲大程序的构成与扩展？主要是实践的需要。因为但凡是有一定用处的软件，在工程实践中，大多都非一个模块所支撑。有几个到几十个动态库、静态库，都是很正常的，也是在所难免的。关于静态库与动态库的编译和连接，以及它们的优劣，在前面介绍了很多，这里就不再重复。库的方式，不单单在节省系统存储和内存上有很大优势，而且，在模块化协助方面，也是有很多用处的。比如，将一些功能相对独立的模块，编译为动态库，然后配合头文件，既可以提供给企业内部，作为隔离；也可以提供给外部，进行集成。这样可以避免核心代码外泄，便于商业应用。而且，无论是在内部还是外部，模块的替换、更新，都会方便很多。如果涉及到升级，也不用整体升，只需要替换相关的动态库就可以了，不仅可以减少升级包的大小，也能够简化升级流程，较少对用户的干扰，提升用户体验。
如上图所示，一个软件，我们可以认为是由很多部分拼接而成，每个部分都承担了一定的功能。可执行文件本身作为对外交流的入口和接口，承担了总控制器的角色。而构成程序的各个库，则是一个个独立的功能模块。除了程序自身独用的库，在现代系统环境下，每个程序还会用到操作系统或者语言本身的库，比如加载库的库，C或者C++标准库等。这就是上图中最底层的依赖库部分。
除了库的概念，我们常听到或者遇到的，就是插件的概念。相对于动态库，插件是一种更加延后的扩展技术。只要约定好同主程序的接口，那么同样的功能，就可以由不同的人，开发不同的插件来完成。插件技术，也广泛存在于软件工程实践中。
关于插件本身的实现方式，可以是动态库，也可以是一个新的可执行程序，还可以是脚本等等。
插件是一种遵循统一的预定义接口规范编写出来的程序。应用程序运行时，通过接口规范对插件进行调用，以扩展应用程序功能。插件是提供运行时扩展的很好的技术，当然也有其优缺点：优点自然是扩展个性化的功能，或者可以通过第三方来做很多功能；缺点是复杂，还有安全性、稳定性，这是自然而然引入的。插件典型技术代表有com技术，activx等。浏览器是我们最常接触的、频繁使用插件的软件之一。
下面对插件常采用的具体技术展示讨论。
1 动态库方式。
采用动态库方式，模块跟主程序运行在一个进程空间中。动态库的使用，本质上是借用操作系统提供的机制。这种模式，有两种使用方式，一种是链接时告诉操作系统，我要用到某个动态库，这样编译时会将依赖库信息带到可执行文件中。可执行文件加载时，操作系统检测到需要依赖的动态库，然后到系统环境指定的目录下，找到相关动态库，加载到内存中，供程序使用。如果依赖的动态库已经加载到内存中了，那么，就共享代码空间，从而节省了内存使用。这其实就是虚拟内存提供的支撑。另外一种方式，是在运行中，通过相关接口，主动加载指定目录下的动态库，并提取其中的接口。这种方式灵活性相对更大一些，但是使用相对麻烦一点，属于动态库的延后加载。当然，这种延后加载，比较适合做插件功能。
2 可执行文件方式。
这种方式，模块跟主程序运行在不同的进程空间中，二者通过进程间通信来交互。如何理解这种方式呢？举个通俗的例子。首先，主程序通过特定规则查找或者通过交互接口加载
（运行）可执行文件插件。可执行文件运行后，根据约定规则，采用进程间通信方式，将自己的特性注册到主程序中。主程序接收到信息模板后，将其通过特定接口暴露给用户。这样，用户就可以看到主程序多了一部分功能。当然，插件也可以主动注册到主程序中。
3 脚本方式。
脚本方式其实可以理解为是规则方式。这种规则，主要由主程序的开发者来定义。当然，也可以使用一些通用的规则。怎么理解这种方式呢？可以这样想，我们认为主程序不仅是一个执行自身逻辑的程序，还附带有一个解释器。这个解释器可以专门用来解释规则，执行规则。就相当于程序中存在一个小机器。更通俗的讲，就是一个小虚拟机。这样一来，我们就可以将规则确定的脚本理解为小程序。二者配合，就可以很灵活的实现插件功能。
当然，这些不是实现插件的所有方式。只要满足系统的运行要求，可以有各种各样的扩展程序功能的方式。所以，就看你的想象力了。就像俄罗斯套娃，每一个都是自我完整存在的世界。你也可以在一个程序世界中创造另一个程序世界，从而扩展创世者。
参考：前面所说的程序虚拟内存，可参考下图（第七章已说明）：
程序的扩展不能无序进行，就像操作系统对应用程序的要求，当我们的程序变成一个具有平台意味的程序后，同样对其扩展有一定的要求，这就导致架构的需求。架构或平台的这种要求，目标是统一而不失单调性，既有规则，又有自由。下面我们就来看看架构。
