隐喻是由团队提出一个程序工作原理的公共景象。它可以帮助我们从整体上把握系统的全局，使得描述问题非常直观。

团队在做插件系统的时候，我们拿到的只有Rose图，和一些基本设计的思路文档，但对于插件系统究竟是什么，每个人的理解深度、方式都不一样。究其 原因，就是因为我们没有一个直观，形象的描述系统的一个东西。概要设计文档是不能算的，太粗且不形象。这个时候我们需要的就是一个隐喻系统，帮助团队统一 认识，使得交流更加有效，或者更加有趣。

一、插件是什么

插件就是积木。

积木有自己的形状、颜色、质地。

1、积木的形状是插件的接口，只要两个积木的形状吻合——两个插件的接口匹配，就可以组合起来。

2、积木的颜色是插件的外观，对于一个已经集成到系统中的插件，外观是可以随意变化的，也就是说系统是否能正确运行和插件拥有什么样的外观没有关系，只是不同的外观会带来不同的用户体验。当然外观也是非常重要的。

3、积木的质地是插件的实现，同样对于系统来说，插件的实现是可以随意修改的，只要形状一样就可以集成进来。也许积木在不同的地方摆放对实现的要求 是不同的。比如说要放在积木的最低层，但却是用海绵做的一块积木，这样上面的积木非常容易倒。如果一个插件是非常基础的插件，但在实现上性能不够好，依赖 于它的插件可能就根本跑不起来。

4、积木是可以组合的，两个或多个积木组合在一起可以当作一个大的积木来用。两个或多个插件组合在一起同样可以当作一个大插件来用。

5、积木可以重用。以前在其他地方用过的积木可以拿到这次来使用。对于以前开发过的插件，一样可以重复使用。

more...

二、插件系统是什么

插件系统就是由积木按照意愿搭出来的模型。

1、积木可以并行制造——插件可以并行开发。

2、积木可以随意组合——插件系统可以根据配置来生成。配置文件就相当于搭积木时的图纸，虽然都是同一些积木，但根据图纸可以搭出不同的东西。

3、玩积木分三个阶段，做积木、搭积木和搭好积木后叫人过来观赏。插件系统分三个阶段，做插件、组装插件、生成系统给用户使用。

4、搭积木很繁琐，并且需要创造力——插件系统组装很累。

5、积木质地不够好，或者两个积木本来形状不匹配却放在一起，这样搭出来的东西容易垮掉。插件系统中，如果插件实现有问题，或者配置文件有问题——将接口不匹配的插件组装起来，这样很容易造成系统崩溃。

6、积木搭出的模型可以随时修改。插件系统能更好地面对用户变化和地区特性。“什么，用户不要这个功能？”那从系统中拿掉好了。“这个功能用户想要改一下？”那把这个插件修改就好了，其他地方没有影响。

more...

三、用户不要积木

系统最终用户并不关心你的系统是用什么技术实现的，他们只关心买这个软件是不是真的能帮他们做事（一群没有艺术鉴赏力的家伙）。但软件的核心是用户，所以虽然我们采用的是插件技术，但却不能把一堆插件丢给用户，说“你想要什么就自己搭吧，想要的都可以搭出来。”

插件只是半成品，不能给用户带来商业价值，所以我们需要将插件组装成一个真正的系统再交给用户。有点像现在可以买到的拼图游戏，一个盒子里面装的全 是纸屑、碎片，一般还有一张最终效果的示意图，没什么人会觉得这些纸屑可以给人带来美的享受。只有等到好事者们将这些纸屑一块一块拼接起来，我们才会发现 “哦，原来这幅画还蛮好看的。不过这张纸好像到处都裂开了，影响美观。”

说这些的意思就是，用户不要积木，并且要尽量地将积木这个事实从用户的视角上掩盖掉，然后告诉他们，我们的系统是变形金刚。这样就好了，让他们琢磨去吧。

四、不太好的隐喻

将插件比作积木的隐喻能解决很多问题。包括我随后会写的关于插件系统组装策略的解释。这样的隐喻能更加形象地告诉别人插件是什么东西，交流起来更加方便。

不过我想的这个隐喻并不能涵盖所有的问题。比如插件之间的动态交互就不能用积木隐喻来解释。不过暂时没有想到更好的。

关于隐喻有一点要说明的，隐喻最好从自然界或者社会人事中来，这样更加容易理解。如果团队中有一种领域是大家都了解的，那也可以。比如说如果团队对足球都很清楚，那么用球队来比喻某个系统同样是可以的。
原则就是，要用具体的东西来隐喻抽象的软件系统。如果用抽象来隐喻抽象，那只是换了个说法，没有任何意义。