今天又没动手，人越来越懒了啊！总是在想，既然功能基本正常，就不要去动它了。就像Martin Fowler在书中说的一样。感觉有心无力，唉，心中有那么一点畏惧和抵制。
不过后来花了点时间，在纸上乱画，针对自动联想功能，清理了一下设计思路。现在的实现真的是很C风格化，所有的代码都是揉合在一个类中，所以相关的功能都在这个类里实现。重构时，希望尽量向OO的方向靠拢，那些设计准则，也要尽量地遵守。
从现存的代码看，自动联想从表现上看，可以分为3类，分别是Auto Completion、Call Tips、Code Snippet。其中Auto Completion是通过已输入的几个字符，根据上下文环境，给出候选的可能匹配的完整token，Call Tips则是在当输入函数调用的实参时，以tooltip的形式给出函数原型以提示，而Code Snippet则是在用户触发了事先绑定的事件时，根据已输入的字符，或者也可称为命令符，自动以代码片段替换该代表命令的字符串。总之这3种特性都是为了减轻编码者记忆负担，减少键盘敲击次数，降低出错概率。
当前的实现是当打开一个文件时，或者截获到换行操作时，进行扫描，记录当前文件及其相关包含的变量和常量的定义，除了名称，还需要类型。这样在输入变量时，可以根据名称进行提示，输入方法时，根据类型可以从数据库是查询到相关方法。所以扫描是为了Auto Completion和Call Tips作准备，Code Snippet不需要这些。
当初实现这些特性时，只考虑到了Ruby语言，所以紧紧围绕着Ruby这个主题开展，代码几乎没留下任何一丝空间以供后续扩展。不过既然这次要重构，无论从设计角度，对象职责上看，或是以后要添加扩展新语言支持，都需要把这块代码剥离出来。一个重要的原则是，剥离出来部分不能再跟界面有耦合了，不然单元测试几乎不能做了。
界面部分还是全都放在控件类中，控件类调用Auto Completion、Call Tips实现类获取待显示的内容，实现类应该从统一从一个抽象类继承，每个实现类可以对应一种（或一类）语法。这里需要引入一个工厂类。原来的助手类应该拆分成两部分，即代码扫描分析部分和信息存储查询部分。其中代码扫描部分也有一个抽象基类，从它派生出对应各种语法的具体实现类，把扫描分析的结果存储到信息存储部分，同时，信息查询部分从信息存储部分获取内容，信息存储部分的数据一部分来自于扫描分析部分，另一部分来自于固有持久化层，可能是一个数据库，可能是一个文件文件，可能是一种外部输入数据结构。这样，任何一部分的变化，都会尽可能少地影响其他部分的实现，而且这些实现除了界面相关部分，其他的应该都比较容易做单元测试，自我感觉设计得不错，只是可能工作量大了不少，很容易让人产生放弃的念头，呵呵！
支付宝扫一扫
微信扫一扫