桌面模块设计与实现回顾
转载时请注明出处：http://blog.csdn.net/absurd
桌面模块的实现基本上告一段了，这里做个总结，把其中的得失写下来，供来者参考。
据以前的经验，桌面模块是比较复杂的。介于它的特殊的地位，容易把它当作杂物箱，什么功能都往里面放。比如系统初始化、密码验证、锁屏、系统事件(如，新事件、设置改变、主题改变、时间改变和磁盘满等)等、甚至MMI的事件也通过桌面中转。还有桌面的本职工作：状态栏、操作栏、开始菜单和桌面区上可见的功能。桌面的界面也是最易变化的，桌面的SPEC到产品快要发布了还在变化，客户也经常要求实现个性化的桌面。这一切的一切，让桌面模块的复杂度与日剧增。桌面的代码渐渐的腐化了，散发出各种代码气味。
有了以前惨痛的教训，我们在开始桌面设计时就采取了比较谨慎的态度。总的来说，桌面模块的实现还是比较顺利的，这主要得益于以下几点：
1. 基于插件式的设计。
为了降低系统的复杂度，我们决定把桌面分为核心功能和扩展功能两大部分。核心功能只是一个框架，或者说是一个容器，扩展功能全部以插件的形式加入进来。这样，核心功能变得非常简单。框架和插件之间通过一个预先定义好的接口通信，两者是一种松耦合的关系，只要接口不变，它们各个独立变化，互不影响。
各个插件之间的关系更加松散，基本上没有联系。每个插件只实现单一的功能，所以不但实现起来比较简单，而且更能适应需求的变化。另外，各个插件的实现基本上没有依赖关系，可以让多个软件工程师参与进来，让专家去写专业的插件。
基于插件式的设计不但降低了系统的复杂度，实现更方便，而且调试也更简单。如果程序出错了，你可以先去掉所有插件(从配置文件中删除就行了)，看看框架工作是否正常。如果框架工作是正常的，再加上你怀疑的插件，一一进行尝试，很快把错误定位到一个极小的范围内了。
2. 自动代码产生。
为了利用gobject的引用计数和订阅-发布(signal)机制，桌面决大多数的类都是从gobject继承而来的。编写gobject的子类比较麻烦，要定义大量的宏，要手工实现多态机制机制，安装对象属性和创建signal尤其乏味。
单调重复的工作一定有规律可循，有规律可循就可以让程序自动完成，这是我们一贯的原则。幸好，在此之前曾开发了一个叫gclassfactroy的小工具，它可以根据用XML定义的IDL，自动产生gobject子类的框架代码。使用gclassfactroy自动产生代码，大大加快了桌面的开发速度。
3. 迭代开发。
在实现过程中，我们采用迭代式开发。先实现基本功能，让程序运行起来，再逐渐添加新功能，并完善它，而不是采用休克疗法。这保证系统随时都可以运行，为我们测试系统功能提供了便利。当功能完全实现时，系统也稳定了，省去了单独的测试时间。
4. 测试驱动。
我们开发了一些测试程序，每实现一点功能就测试它，保证它的质量。尽管这些测试程序不是自动测试的，对我们的帮助仍然很大。一方面利用这些测试程序去验证已经实现的功能，保证系统的质量，同时这种及时的反馈也增强了我们的信心。
在桌面的设计和实现过程中，也遇到一些问题，其中最大的问题就是：对桌面项的包装过多(通常为三层)，造成signal的流向比较混乱，后来制定了一个原则：函数只能从上往下调，signal只能由底层向上发，基本上解决了signal混乱的现象
~~~end~~