SICS编程指南 1 序言

在经过了前面的长篇叙述之后，我开始犹豫：是否真的可以向大家讲解SICS的实践应用了？

牛虽然吹得震天响，但是真到要开始面对众多行家里手的时候，我不得不说：作为SICS的作者，虽然我清楚它的能力，却也非常清楚它的一些缺陷（严格来说， 有些缺陷甚至非常严重）。虽然这么多年来，我一直在对SICS的体系和功能进行完善，但是依然有一些问题没有得到很好的解决。

对于技术方面的问题，我通常都是力求完美和统一的，SICS中的这些缺陷之所以存在，实际上是因为我的技术和经验依然没能到达足以解决这些问题的所要求的境界。

我将这些欠缺分为几种类型，按照严重性分类，包括：

1）功能涵盖错误，或者语义定义错误。这样的错误通常会直接导致系统结构设计混乱，以至于前后矛盾，冲突难解。作为一个非常底层的应用框架，其语义设计难 度之高绝非一个普通应用级程序员所能想象。我常常为一个对象（类）的一个方法的取舍和确定苦苦思索，反反复复，却依然不得其途！应用级程序员通常不会非常 关心这类问题，只要采用一个“本地合适”的方法就好；然而，对于一个底层支撑框架来说，所要求的甚至是一个“放之四海而皆准”的定义！

2）功能整体不足，且因为设计不当导致系统难于扩展。如果仅仅是功能不足，那么这个不是什么太大的问题，俗话说：条条大路通罗马，换个思路设计就是，但是 如果对这类不足考虑不周导致系统自身难于扩展，那么，就成了死胡同了。在SICS中，这类缺陷是我比较重点注意避免的一类缺陷。虽然不敢说肯定没有，但是 至少在我的能力范围内已经为未来的功能扩展做了大量的准备工作。

3）界面支持不足，功能无法展现。这类缺陷应该说是SICS中存在最多的一类,甚至多到如果用“缺陷”来描述简直是对“缺陷”的侮辱的程度，所以我甚至都 不认为它是什么缺陷了！说实话，对这方面我的确不是非常关心，因为就目前来说，在我手头的版本的实际用户或者应用本身也不是很多，还没到需要非常重视的程 度。

所以，我所说的缺陷基本上是指第一类缺陷。在“这样”或者“那样”之间的考察很难有非常肯定的结论，冗长和重复的定义肯定是因为一些自己未能明白的道理，所以，SICS之所以会成为现在的样子！

而我之所以准备按照现在的模样发布关于系统编程指南，绝没有完全肯定现在的设计的意思，只不过是想对大家说：“目前，SICS是这样的......"