在Unix之失的讨论中,我们谈到过X系统的设计者在设计中的基本抉择是实行“机制,而不是策略”这种做法——使X成为一个通用图形引擎,而将用户界面风格留给工具包或者系统的其它层次来决定。这一点得以证明是正确的,因为策略和机制是按照不同的时间尺度变化的,策略的变化要远远快于机制。GUI工具包的观感时尚来去匆匆,而光栅操作和组合却是永恒的。
所以,把策略同机制揉成一团有两个负面影响:一来会使策略变得死板,难以适应用户需求的改变,二来也意味着任何策略的改变都极有可能动摇机制。
相反,将二者剥离,就有可能在探索新策略的时候不足以打破机制。另外,我们也可以更容易为机制写出较好的测试(因为策略太短命,不值得花太多精力在这上面)。
这条设计准则在GUI环境之外也被广泛应用。总而言之,这条准则告诉我们应该设法将接口和引擎剥离开来。
实现这种剥离的一个好处是,比如,将应用按照一个库来编写,这个库包含许多由内嵌脚本语言驱动的C服务程序,而至于整个应用的控制流程则用脚本来撰写而不是用C语言。这种模式的经典例子就是Emacs编辑器,它使用内嵌的脚本语言Lisp解释器来控制用C编写的编辑原语操作。
另一个方法是将应用程序分成可以协作的前端和后端进程,通过套接字上层的专用应用协议进行通讯。前端实现策略,后端实现机制。比起仅用单个进程的整体实现方式来说,这种双端设计方式大大降低了整体复杂度,bug有望减少,从而降低程序的寿命周期成本。
阅读(2842) | 评论(0) | 转发(0) |