本帖最后由 djyos 于 2012-8-6 22:32 编辑
降低模块间耦合，提高应用程序可靠性
另一个会严重降低应用程序可靠性的地方，就是模块间互相耦合，搅在一起。搅在一起的代码，就像一盘意大利面条，又杂又乱，如果代码写成这样的话，可靠性要高，上帝都会笑。 那么，避免意大利面条式的编码，全是应用程序的责任吗？OS作为基础软件，就一点责任都没有吗？这显然是不对的，只是大多数OS开发者没有意识到这点罢了，他们只讲究OS自身的高汇聚低耦合，忘记了OS的基本职责。消防部门的职责不仅仅是救火，更重要的是防火；OS的职责不仅仅是把出错的应用程序杀死，更重要的是帮助用户设计正确的应用程序。前面讲到，djyos的中断设计，可以消灭用户错误地调用系统服务的错误，但这只是帮助用户设计正确程序的初级阶段，帮助的只是程序员；那么，帮助用户，甚至是迫使用户编写高内聚、低耦合的模块，降解模块间的相互纠缠的关系，才是高级阶段，帮助的是系统工程师。 许多操作系统，描述自己功能强大时，总是喜滋滋地宣称自己的api多么丰富，程序员想干什么都可以支持。其实，api不是越多越好，甚至有些api是有害的，比如线程间（对应djyos的事件）互相直接控制的api，包括但不限于： 线程无条件挂起； 直接唤醒别的线程； 设置别的线程的优先级； 杀死别的线程； 等等……
这些功能，咋一看上去，是帮助程序员控制程序，但实质上是有害的，以“线程无条件挂起——直接唤醒别的线程”这对冤家来说吧。 写过C代码的都知道，goto是很受忌讳的语句，甚至有人根本不用，而提倡用if、for、while来实现程序转移。那么，大家有没有想过，我们为什么这么忌讳goto呢？为什么偏爱if、for、while呢？因为goto是很粗暴、不讲道理的转移，而if、for、while呢，它清楚地说明了转移的原因和条件，有理有据！我们对函数内的goto耿耿于怀的同时，却无视长期存在的、组件之间、线程之间的大GOTO，甚至有些操作系统还为提供了丰富的大GOTO为卖点，说什么为应用程序提供丰富的服务。 什么是大GOTO呢？操作系统环境下编程，一个线程往往代表一个独立模块。绝大多数操作系统提供了无条件的线程休眠、暂停和唤醒功能，线程执行到任何时候，都可以无缘无故地倒地就睡，cpu将转而执行另一个就绪线程，就像用GOTO跳转到另一个线程一样，究竟跳到哪个线程呢？不知道！小goto还有个标号让你知道跳到哪里，大GOTO则连跳到哪里读不知道。线程睡着以后，自己是不会唤醒自己的了，但其他任何线程都可以无条件地把它唤醒，这又涉嫌模块间互相操作。因此，无条件的休眠、暂停和唤醒，使程序的执行过程跨模块地搅在一起，是模块间失去独立性，如果两个线程是由两个团队独立开发的，则属于两个团队间交叉跳转。 因此，djyos不提供任何类似的操作，所有事件都是自己控制自己的行为，没有任何事件处理函数间交叉控制的可能。djyos并不是不让事件暂停、休眠和阻塞，只是像if、for、while一样，要求程序员说明理由，为此，djyos提供了丰富的同步功能，程序员使用这些同步函数，明确告诉操作系统，自己停下来的理由，以及明确的唤醒条件，由操作系统检测到这些条件成立后，唤醒自己。这样，应用程序每个事件都自己控制自己行为，从而彻底避免了应用程序模块之间直接的交叉控制。也就是说，djyos中不存在跨事件（对应其他操作系统的线程）的大GOTO。 一个线程，直接控制别的线程的优先级，也是很致命的，一个线程的优先级，属于其核心内部数据，在面向对象的思想中，是最应该隐藏的信息。而直接被别的模块控制，还谈什么模块独立性。Djyos的djy_set_prio函数，只能设置正在执行的事件（对应其他操作系统的线程）自己的优先级。
如何管理数据，是降低模块间耦合性的重要一环，有经验的系统工程师，拿到项目后，首先想到的，是如何组织和管理数据的问题。广义上，应用程序需要的一切数据都是资源，DJYOS操作系统系统提供一个简单易用的资源管理模块，用于管理用户比较关注的、对程序运行意义重大的资源，并提供了丰富的资源管理api函数。在DJYOS资源管理模块的协助下，应用程序管理数据将变得非常简单。更主要的是，如果用户坚持用资源管理器管理所有数据，将使不同的软件模块实现细节上获得惊人的一致性。一个有一定规模的软件，必然要划分为若干模块才能顺利开发，如果不加约束，各模块可能各自设计自己喜欢的方法管理各自的数据。这种不一致性将增加软件的复杂度，增加阅读和修改软件的难度，而且，这样不可避免地会增加软件规模，增加编程和测试的工作量。若要在开发团队内和团队间人员调配，新人将花较多的时间熟悉新模块，而如果各模块代码有一致性，就会降低人员调配时交接工作的难度。
| 
发表于 2012-8-6 22:28:33
楼主
