set nocompatible source $VIMRUNTIME/vimrc_example.vim source $VIMRUNTIME/mswin.vim behave mswin let Tlist_Ctags_Cmd = 'D:\Program Files\Vim\vim64\ctags.exe' set autochdir set nois set tags=tags set nowrap set guioptions+=b set ts=4 set sw=4 set gfn=Courier_New:h10 colors vxdarkblue ………vim自带的这一部分就不帖了 endfunction |
月度归档:2005年12月
vim
appfuse generator的编码规范
Ruby vs Java? and appfuse
《新技术倍出 谁最可能挑战Java开发优势》,感觉挺恶俗的一个名字。不过既然要圈钱就得制造点事端,制造点热点。一个东西不管好不好,有人理就是好事。
JAVA,为什么又是JAVA不是PHP、ASP。因为JAVA红,俗话说人红事多。现在的新人为了吸引眼球总得拉个大腕作幌子,就象前一阵子天涯上的猫人。JAVA,因为JAVA红。
又是Ruby,又在CSDN上看到关于Ruby的帖子。我一直都承认我对脚本语言是存在偏见的,而且固执己见。
Ruby可能流行吗?可能。 Ruby能挑战Java吗?表示怀疑。
JAVA其实可以更简单,JAVA目前的这个局面更多的是因为厂商利益。在Ruby开始威胁到JAVA的时候,JAVA可以变得简单起来。而且在提供方便性将在一定程度的限制功能。有时候,一个东西完善的过程,也是一个复杂化的过程。我觉得Ruby应当是这样的一个东西。最重要的一点,Ruby的定位和JAVA不一样。JAVA定位相对比较高一些。要抢底盘也是抢PHP的,JAVA受到的威胁相对要小一些。
又想到了APPFUSE。APPFUSE一个不错的集成框架。而且自身带的代码生成器使用也很方便。只要写完VO并为VO写上XDoclet的标注后,直接运行ant命令就可以自动完成数据库的部署并将包括表示层的所有相关代码生成。完全一站式的代码生成。
既然APPFUSE如此完美为什么没有广泛的流行起来?
Appfuse基于脚本的代码生成,对细节封装得不够(或者说隐藏吧)。虽然完全按照Appfuse的预定流程来作很方便,可以实现对开发细节的隐藏,但在大多数情况下大家都需要对框架进行扩展来实现自己的需求。既然要扩展,你就必须要了解框架的具体实现细节,而appfuse使用的技术N多。如果要熟悉还是得花些时间的。
说到这里可能很多人要说到JAVA的复杂性了。对,JAVA很复杂,但同样也可以很简单。虽然技术多,但并不不代表你要了解的东西要很多。技术是用来简化开发的,如果一个新技术的出现反而使开发复杂化了,那这个技术是不值得采用的。在appfuse中采用的新技术都是有其价值的。appfuse缺的是文档。不光是appfuse的文档,还有appfuse所采用的技术的相关文档。这些文档不需要很复杂,只要那么一两页纸告诉框架的使用者这些技术是用来作什么的。对于这些技术只介绍必要部分,暂时用不着的都不用讲,尽量简化(隐藏)框架的复杂性。
appfuse中大量的使用了ant脚本来实现自动化。但也正是由于过于依赖这些脚本,导致框架和IDE的结合不是很好。到目前我还不是很清楚怎么用IDE对appfuse进行调试。虽然这很可能是因为我对appfuse的研究不够,但对于一个以方便为目的的框架,不应该将和IDE的整合交给框架的使用者去作。
还有就是appfuse的那个权限系统实在是让人有些不爽。不同系统对权限系统的要求都不一样。权限系统这一块本该是可以灵活配置的,可以很方便的从系统中移除,自己实现。但appfuse的权限系统和框架绑这么紧,要分出去多少还得话些时间。
说了这么多appfuse的“坏话”,不过还是希望appfuse能快速成熟起来。对appfuse来说功能不是问题,最大的问题是人性化,JAVA也是这样。
PS:最近看到appfuse有个代码生成器的子项目appfuse generator。用Velocity替代xdoclet作为模版生成引擎。刚开始研究,还不清楚和appfuse里面集成的代码生成器相比有什么优势。
新版本的appfuse集成了一个缓存系统,有时间可以研究一下。
eXtremetable
OOP程序设计实践
前言
phoenix,浴火重生的凤凰。和她的名字一样,这个版本的热键助手是一个全新的热键助手。虽然她“长得”和以前的版本差不多不过她已经实现了程序的全部重写。
应当说phoenix版本是“热键助手”的降级版。在以前开发“热键助手”的时候,按照自己的喜好加了很多功能。然而在实现了这些功能以后,却发现真正使用这些功能的人其实并不多。这次开发的出发点是实现基本的功能,在用户需要时再根据具体情况添加。
OOP
其实这次重写“热键助手”主要是对OOP的实践。在以前写程序的时候总是喜欢把不同的功能放到不同的单元中,把不同的功能放到不同的函数中……。当时感觉这样写程序就已经很帅了,但始终感觉没有摸到OOP的门。然而就在最近开始有点OOP的感觉了,于是决定将“热键助手”进行一次重写。
重写的过程中问题还是不少的。
在设计的过程中颗粒细度始终很难把握。因为是初次使用OOP的思想来做程序,在划分模块的时候经常“狠不下心”,老是希望把颗粒划分得比较细,舍不得将颗粒画粗点。不过根据XP的说法,不应当在程序设计的初期把程序设计得太“完美”,因为你的能力会在设计的过程中提高的嘛。一些东西以后做也许会做得更好,而且现在计划的很多东西在以后可能会变得毫无用处,为什么要浪费这么多的时间来做一些无意义的事呢?而且只要前期的设计不要做的实在太烂,在后期还可以比较方便的使用重构来改善程序结构以适应需求的变化。
程序具体结构(还没完成)
下图就是程序的类图,因为还没真正完成所以在最终实现的时候应当还会做写修改。
下面还是对程序的结构进行一些讲解吧。(其实类图提供的信息已经蛮详细了)
TvxShortCut类对热键(TvxShortCut)进行统一管理管理。在TvxShortCut有一个TvxSettingMgr的引用,通过她来进行对设置文件的操作。TvxShortCut应当是一个抽象类(目前还不是),因为她没有和界面打交道的代码,她的界面相关部分将在子类中实现。
TvxSettingMgr用于实现配置部分的功能。其实可以将其设计成一个接口。其具体实现可以由TvxXMLSettingMgr等实体类来实现。不过目前还没有采用其他配置方式的想法,所以先这样做吧,等到有必要的时候再考虑重构。
TvxShortCut用于实现热键的注册和卸载等功能。TvxShortCut应用TvxScript执行热键操作。
TvxScript对脚本进行分析,并调用TActionFactory来构造一个TvxAction接口的类来执行具体的脚本。(我觉得TvxScript这个类好像有点小问题,但具体怎么改还想不到,所以先这样用吧)
TvxAction执行热键的具体操作。这是一个抽象类,她的具体实现在她的子类里实现。
TvxMenuAction类,实现了IvxMenuInterface接口的Action类,可以将其添加到Menu上。这也是一个抽象类。
TvxOpenFile类,TvxMenuAction的子类,用于具体实现打开文件的操作。
IvxMenuInterface接口,添加到Menu的接口。
TvxSubMenu类,有子菜单的菜单项目(分隔符也算到这里面,反正是和Action无管的菜单项)。
TvxMenuMgr,具体将实现了IvxMenuInterface类的接口添加到菜单上。
差不多就这样了。因为我也是OOP的菜鸟,设计方面还是很菜,而且自我感觉上面的类图还有不少问题,如果大家有什么好的建议欢迎指出来。
备注
在设计的时候我也一直在象,我是不是将问题复杂化了。不过OOP的第一步始终要走出去的,所以就算是再硬的核桃也要将其砸扁。
顺便祈祷这个程序可千万别夭折了,就算是再烂也还是写完先。(在接下来的一段时间里工作会很忙,不知道什么时候可以将程序写完)。
发表于 @ 2004年10月
//——————————————————————–
PS:
很久以前的东西了。最初是放在我的个人主页上的,不过我的主页空间到期后就没有继续维护了(两年过得可真快啊)。这篇文章在CSDN也有,不过CSDN的blog在发完这个文章后就已经没有进行维护了。CSDN的blog上总共也就只有这一篇文章,差不多也算是废了。想想我还是很少写技术文章的(妖言惑众还是比较多的),这个文章虽然说写得不怎么样,但多少还是有点回忆吧。OOP走火入魔的回忆,当然这个走火入魔更多的带有一些刻意。 爱爱过才知情深,醉过才知酒浓。只有有过走火入魔的经历才能将问题看得更透彻。
程序也早就完工了,不过最后的结构和上面的类图有些不同。
程序的最新版本和以前的发布版本相比有些小改动,而且修正了一些内存泄露问题。只是中文版的程序在一次意外硬盘灾难中丢失了。E文版的还有,不过帮助只E文化了一半。现在程序的帮助还是一半E文,一半中文的。是否考虑那天将剩下的帮助也E文化后发布个E文版的?
不知道怎么将MSN上传的图片插入到blog里,而且上传的图片会显示在“我的图片”里,不是很美观。所以文章中的图片是在网上拉的别人家,图片什么时候实效我就不清楚了。