AI结构中，有一种情况非常容易出现，就是程序员会非常希望有一块区域，大家可以读取，存储一些信息，并且这块区域是全局共享的。不管是写作看似丑陋的全局变量，还是有一定组织的Blackboard结构，或者作为参数一路传到底，这种结构可以被统称为共享数据（Share Data）。作用就是在不同的模块间传递变量。

共享数据的需求，从某种程度上说，源自程序员的一种”偷懒“（当然这里没有任何贬义），试想一下，一块可以非常方便，存我想存的，读我想读的结构，一块非常松散且容易理解的结构，一块非常容易架构（或者几乎不用架构）的结构，相信很多人都会作为第一选择吧。确实，共享数据的优势很大，很有吸引力，在开发中，可以作为很多问题的解决方案，几乎在所有的引擎中，都或多或少存在着一些共享数据的模块。

在网上的很多文章里，探讨了多种共享数据的结构，OO开发，使得这种结构多了更多的灵活性，不再是以前一个structure走天下了，比如前面说到黑板系统，这个可以说是现在AI中经常会用到的结构，在FEAR的GOAP里就用到了Blackboard，用作在Planner间作数据共享（以后可以写篇文章介绍一下GOAP，我非常喜欢的一个AI架构）。但不管这么样，共享数据的本质还是相同的。

共享数据是一种优点和缺点同样明显结构，下面我们来看看它的缺点

首先，就是共享数据很容易乱，这是伴随它的随意性而生的，共享数据的内容会随着开发进程不停的被修改，或添加新的变量（这种情况居多），或删除冗余的变量（由于开发过程是多人协作的，所以，非常有可能的一种情况就是存在两个作用完全相同的变量，只是因为是不同的人加的），如果没有好的维护和清理，共享数据就会逐渐变成”垃圾堆“ — 随便说一句，这也是我对共享数据的昵称

其次，共享数据会比较难debug，因为修改和读取都是匿名的，也就是说，谁也不知道，谁会在什么时候修改什么变量！这会导致变量被莫名修改，当然，加数据断点，或者好的统一入口，会使情况有所改善。

还有，共享数据很容易造成程序员对他的依赖，会认为任何变量都可以存在其中，而忽视了对本身模块的架构，在某些情况下，它会成为解决问题的最后一棵稻草，问题是，共享数据可以是，但不能每次都是！

像我写的标题，”黄金屋“还是”垃圾堆“，不取决于共享数据本身，而是取决于，我们如何去实现，如何去维护，如何去规范，如何去使用。想到这个问题，也源自我最近一段时间的实践和体会，作为一个新的系列的开始吧，下一篇，写点我对架构共享数据模块的想法。

————————————————————————
作者：Finney
Blog：AI分享站(http://www.aisharing.com/)
Email：finneytang@gmail.com
本文欢迎转载和引用，请保留本说明并注明出处
————————————————————————