版权声明:本文同时发表在www.j2medev.com和我的Blog(blog.csdn.net/alikeboy)上,如果需要转载,有三个途径:1)联系我并经我同意;2)和www.j2medev.com有转载文章合作协议的 3)通过Rss聚合我的Blog。另外网上转载需要全文转发(包括文章的头部的声明),不要断章取义。
正文:
Note项目描述
手机是一个真正随身携带的数字终端,我们除了利用手机打电话、发信息外,往往让他帮助我们记录文字性的信息。PDA有较大的屏幕和手写输入的功能,而手机上的记事功能有限,记录的内容很简单。可以说利用手机记录信息是一种被视为理所应当的功能,也造就了一个一系列的应用——将手机作为随时随地的信息收集器。不难设想此类应用会用一定的市场,我们今天选择的Note记事本项目,正是此类应用的单机版的原形。
Note是很多手机的内建应用程序,一般叫做记事本或便签,说明这是一个非常常用的服务。也许朋友们可能认为开发一个已有的程序没有挑战性。是的,在开发上最忌讳的就是重作车轮,但对于教学则可两说着。毕竟一个简单的原型程序不会让我们陷入太多的细节,我的主旨是向大家介绍MVC模式的应用方法。
Note为手机用户提供记录一些简短信息的功能,用户可以添加记录,打开浏览记录,并可以随时修改已经保存在手机上的记录,当然也可以删除它们。就好象Windows下的记事本一样,只不过多了管理的功能。
用例分析
首先设想一下谁在使用这个程序:手机用户。好,我们以后就称这个参与者为用户(user)。
然后设想一下,用户都利用我们的NOTE(中文我们叫做记录好了)干些什么呢?很显然,用户可以添加新的记录,浏览他添加的记录,修改他所添加的记录,并且他还可以删除记录。一条记录应该简单的包括用户对记录起的名字,记录的创建或修改时间,以及最重要的记录的内容。
一般的情况开发人员是很反感这种文字性的描述的,往往是因为开发人员习惯于对待硬梆梆的PC机,而不愿意去面对客户,收集这种需求。其实文字性的东西,既是一个对系统的概述,又是我们发现开发要素的土壤。试想如果你的软件要发布了,你却无法组织起语言让用户恰当的理解软件的功能与使用对象,是多么的让人烦恼。
精练用户的需求(其实是我的教学需求哈哈)。很显然添加记录与修改记录同属于对记录进行编辑操作,就叫做编辑记录用例(NoteEdit)好了。浏览记录也是一个很明显的用例,就叫做浏览用例(Notepad)。删除是对记录进行的一种管理,叫做管理记录用例(NoteManager)。到此,我们已发现并精练了三个主要用例,还不错,系统正一步步变的清晰。在这里提醒大家,这个阶段是站在客户的观点(这里是用户的观点)想问题的,你的工作是发现并系统化客户的想法,不必站在开发者的角度思考任何细节。
编辑记录用例(NoteEdit)
事件流1:
1) 显示用户Note的内容
2) 用户编辑内容
3) 用户放弃修改,note内容不变,正常退出
事件流2:
1) 显示用户Note的内容
2) 用户编辑内容
3) 用户save,退回主菜单
事件流3:
1) 显示用户Note的内容
2) 用户编辑内容
3) 用户save As,提示让用户输入新的文件名
4) Save,退回主菜单
浏览用例(Notepad)
事件流1:
1) 显示用户的Note的标题、创建时间、内容
2) 用户选择退出,返回主菜单
事件流2:
1) 显示用户的Note的标题、创建时间、内容
2) 用户显示编辑,转向编辑用例
管理记录用例(NoteManager)
事件流1:
1) 显示用户的Note列表
2) 用户打开选择的Note,转向浏览用例
事件流2:
1) 显示用户的Note列表
2) 用户编辑选择的Note,转向编辑用例
事件流3:
1) 显示用户的Note列表
2) 用户新建一个Note,转向编辑用例
事件流4:
1) 显示用户的Note列表
2) 用户删除选择的Note
3) 出现确认提示
4) 用户确认,删除Note
5) 更新显示,回到Note列表
三个用例的事件流一经被分析出来了,很显然应该在第一次迭代全部完成。
寻找类(oo分析)
首先是实体类(Entity),只需要从事件流中提取名字就可以缩小范围。
Note,显然是个对象。
内容(content)、时间(datetime)、标题(title),恩,应该是Note的元素。
Note的方法包括对域成员的操作set/get。因为要保存,所以需要序列化反序列化方法。
一般实体类都是由一个对应的生命周期类(lifecycle)用于他的产生、存储、消亡等等操作,一般把这样的操作独立出来大大有利用实体类的重用。不过此阶段还用不着分析他,一会儿画顺序图时,自然就会发现它。
习惯上为了高效的画顺序图,边界类和控制类的方法都需一一列出。不过我们省了,大家只知道每个用例都对应着一个边界类就好了。
设计实践
我举三个用例中管理记录用例(NoteManager)的一部分和浏览用例(Notepad)的一部分来介绍详细的设计过程。在这里,我们试图从一个客户的角度转化到一个开发者角度。要面对很多的挑战,可能包括一部分细节。应该学习从分离的角度思考整个系统。MVC的精华就在这里。
记录用例(NoteManager)事件流1:
(点击查看原图)
NoteManagerUI并不知道Note列表的具体组织形式,它通过预先商定好的接口getNoteTitleList向控制类NoteManagerWorkflow所要数据,控制类返回一个String[]数组。
同样,NoteManagerWorkflow需要向生命周期类NoteLocator所要数据,不过NoteManagerWorkflow知道数据的细节。为了能够识别数据,除了返回记录的Title这一信息外,还要同时返回一个唯一识别的ID作为整个系统内识别Note的方法。所以NoteManagerWorkflow就有了两个域一个是TitleList、一个是IdList。
这里有几个细节:
1) NoteManagerUI、NoteManagerWorkflow如何通信,这不成问题,我们有理由相信他们是紧密相关的。
2) NoteManagerWorkflow如何找到NoteLocator,一般情况下,NoteLoator都是单件Singlton。
3) 当NoteManagerUI的showNote(index),调用的时候,他会调用NoteManager的showNoteDispose(index),而showNoteDispose会根据内部的实现,将这一Index转化为id用于识别Note
浏览用例(Notepad)事件流1:
NotepadUI向控制类所要标题,控制类有域note、和noteid,但是控制类通过getNode,这里很明显的可以使用惰性初始化技术,向生命周期类所要Note。取得记录对象的引用后,你可以方便的像实体类请求数据了。
经验分享
当然了,打好骨架后你就可以开始时coding了,画图的好处是强迫你在设计阶段做好各个部件之间的接口设计。这可以有效地减少你返工的几率,但是往往我们在设计阶段过多的思考了细节,比如NoteLocator是如何和Rms交流的等等。这都是很不好的习惯,但是不太容易改正。因为无论是学校里,还是陪训等等都是训练,反复的训练我们对coding的敏感。我们太依赖于从代码的角度思考问题了,这阻碍了我们从大局思考问题,发现更通用的模式。
如果要开始coding了,也不要一开始就全面铺开,一般实体类具有很强的独立性。可以独立开发,而开发其它类的时候可以从边界类开始,如果想一边开发一边测试一下,大可把控制类、生命周期类的方法暂时用fade data(伪支撑数据),这都是大大降低复杂性的好办法。
有条件的话请进行单元测试,不然测试效率实在是低。(Ps,有人写篇j2me下使用单元测试的文章好吗,我好想让测试自动化)
惰性初始化是我使用的最为频繁的技术,我觉得它可以大大降低代码混乱的程度。
整个系统的UML
(点击查看原图)
有人说看不懂UML,但如果给我这么大的代码,我肯定看不懂。UML吗,有可能看懂:)
屏幕快照
开始后的画面:(管理用例)
新建后的画面:(编辑用例)
按下save,输入title名字
更新显示:
选择你喜欢的浏览,比如标题是easy的记录:(浏览用例)
屏幕导航:
代码种种
有朋友不愿意公开自己的代码,但是对于java来说,反编译太容易了。你没有什么秘密可言。相对于设计来说,代码是个很细碎的东西。如果有人愿意为你修改代码,共同完善的话,那是打着灯笼也找不到的呀,我用eclipse开发,就是在使用开放源码的结晶呀。当然这是对文章的附加代码而言。真正的项目如果开源一定要在GPL下进行。谁也不想再出现divx那样的事了。转载的朋友,再说一遍免费不但等于 not copyright。