Chinaunix首页 | 论坛 | 博客
  • 博客访问: 636243
  • 博文数量: 54
  • 博客积分: 3812
  • 博客等级: 上校
  • 技术积分: 992
  • 用 户 组: 普通用户
  • 注册时间: 2007-04-16 20:53
文章分类

全部博文(54)

文章存档

2010年(10)

2009年(24)

2008年(20)

分类: LINUX

2009-03-24 19:25:52

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