插件管理系统设计

前言

在谈插件前我们先来讨论在日常工作中常遇到的问题：

1. 经过软件开发人员和测试人员长时间的努力，发布稳定的软件版本后，突然接到有对接某一系统的功能需求，这时是否为了这个功能需求发布下一版本？
2. 对接系统的甲方需求经常发生变化，每次发变化都需要更新整个软件？
3. 对接系统非常多，没法完全统一，为应对不同的需求，维护不同的版本？不同版本之间的升级又会引出新的问题，软件的维护压力增大，如何解决？

这里引入插件的方式解决上述问题。
基本思想：把业务逻辑抽象出来，“不变”的部分与“变化”的部分进行分离，变化的变化放入插件部分。

插件本质上是一个动态库。而库，就会有对应的API接口。这里谈一下个人对接口的理解：
个人有过较长年限的C、C++语言编程经验，虽然目前听到的最多的是面向对象编程，但我认为C 中“面向接口”编程的思想无论是对象语言还是结构化语言都很重要。
从项目软件开发的角度，把系统划分为一个个功能模块，功能模块又细分（这里面又涉及到“设计模式”中的一些思想，例如单例职责原则等 ）。模块划分好后，一个很重要的思想就是”面向接口编程“。

这就好比建一座大楼，打好地基后，把建楼的任务划分成每一层，每一层的任务又分成每一间房。每个房间由一个工人负责，工人只在房间内部进行工作，需要砖时对外喊一声”我需要砖，请提供给我“，需要水泥时也对外喊一声”我需要水泥，请提供给我“。而不用关心砖是否足够，其它的房间是否会占用我的砖块和水泥。工人的工作就是专心一心一意的建属于他任务下的那间房子。
这样做有什么好处了：不用为其它的事情散了精力。

软件开发中“面向接口”的前后对比：

1. 方式一: 实现功能模块中的A功能点，依赖外部输入的数据，你会考虑这个数据来源是怎样的，从串口来，还是从USB口来，数据的处理是放在主线程，还是单独开一个线程，数据中间经过了哪些步骤。你会发现当这些细节的事情太多了，想要把它理顺是一件非常艰难的事情。
2. 方式二:实现功能模块中的A功能点，依赖外部输入的数据,我不考虑数据怎么来，我向接口要就可以了，接口会提供给我，至于怎么提供，能不能提供，不是我关心的事情。

思考：对比这二种思维方式，发现有什么不一样的地方?

我们生活在同一个星球，遵循同样的物理规律，很多思维方式在不同的学科以及生活中都是相通的。

就像组织中团队合作，各自团队做好自己分内的事情，站在团队内部的角度不用考虑对方团队能否实现，对方能不能实现不是本团队在执行层面要考虑的事情。（经常会有这样的