挖井

类库大魔王的挖井日记

挖一口属于自己的井


扩展性和通用性

  这两天在想一些问题,怎样构建一个有足够扩展性和通用性的框架呢?
  对Scintilla的使用有了一点经验后,就想好好利用它来做几个有点实用价值的东东,关键就在于想做的不止一个,但在文本编辑方面由于都是使用Scintilla,所以肯定会想到如果能让代码写得足够通用,所有工程都共享一个代码实现就好了,以后即便有了修改,只要修改一次,其他的最大程度上只要重新编译链接一下就可以了,不用再修改源代码。但这样的通用性要如何实现呢,组件化是一种常见的解决方案,这里Scintilla已经是一个现成成熟的组件,但它只是提供了最基本的能力,如果要把这些能力展现出来,还是自己写代码实现。
  有鉴于Impeller项目越来越冗长庞杂的实现,我心里很是不舒服。它确实有那么多事要做,也许有些事不是它的责任,但那也只是极小一部分,但把所有事的实现都放在工程中用C++完成,我就觉得有待商榷了。比如有很经典的一段代码,用于在用户动作触发时,在当前光标所在位置插入日期和时间,这样微不足道的功能,花了好几十行C++代码。其实在大半年前,我还在维护编辑器模块时,我就想通过脚本来支持这些简单功能了,但后来因为这样那样的原因最终没有实现。这只是一个简单的例子,照我的想法,最理想的方案是程序从配置文件中读出相关扩展信息,根据配置在主菜单、工具栏、弹出菜单等用户最习惯的界面上添加可触发控制,当用户触发了这些控制时,程序从配置中读出需要执行的动作,可能是一段脚本,或一个脚本文件,或一个DLL导出函数,甚至是一个COM组件中的一个接口中的方法,总之在被触发前这些东西可是是实际不存在的,也即Eclipse提倡的懒加载规则。这里有几个实现上的难点,如何通过配置文件就动态地实现配置的用户界面;如何通过用户动作立即找到正确的执行动作;如何让主程序和扩展进行交互。一般说来主程序需要提供一些方法供扩展进行调用控制主程序的行为,于是有相应的问题是主程序通过什么方式暴露这些方法,又需要暴露哪些方法。如果这些问题都能解决了,还有另外一个问题,不同的扩展之间是否可以交互,它们的协议应该怎么设计。
  总之在动手做那几个东东前,这扩展性和通用性的问题必须要有一个可靠可行的方案,不解以后自己得累死。

本文地址:

https://minidump.info/blog/2008/03/e6-89-a9-e5-b1-95-e6-80-a7-e5-92-8c-e9-80-9a-e7-94-a8-e6-80-a7/

感觉本文不错,不妨小额鼓励我一下!
上一篇

从文本编辑转向图形编辑

  看了一点SciTE的代码,因为从SciTE可以看到Scintilla控件的各种使用方法,说起来Impeller也使用的Scintilla,但是总感觉很弱,比如SciTE可以同时直接支持UTF-8和ANSI编码的文件,而Impeller就不行,一个时刻只能支持一种,另一种编码的文件打开时,如...…

Job 全文阅读
下一篇

IDE需要什么功能

  在网上看到一个英文博客,有一篇文章作者谈到他希望一个代码编辑器,或者一个IDE应该有什么样的功能。看了之后感觉还算比较客观,基本没有特别个性化的要求,对于要做这方面工作的人很有参考价值。…

Shareware 全文阅读