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