内容提要：

如果想试验一下自己对一个知识到底有几分的掌握，最好的方法就是实践她。结合一个名为“NOTE”的项目（记事本），运用MVC模式进行构建，一起体会一下MVC的强大与灵活。请注意的是，本文中关于不再使用MVC这样的术语，而是使用边界类、控制类、实体类、生命周期类这样的称呼。关于MVC的在j2me上的种种变化请看本文的（一），尤其看看我的习惯做法，否则交流上有困难。

本文重视的是总体设计，细节上没有过多的谈。

I want a good sleep.

 

版权声明：

本文同时发表在www.j2medev.com和我的Blog（blog.csdn.net/alikeboy）上，如果需要转载，有三个途径：1）联系我并经我同意；2）和www.j2medev.com有转载文章合作协议的 3）通过Rss聚合我的Blog。另外网上转载需要全文转发(包括文章的头部的声明)，不要断章取义。

 

正文：

 

 

手机是一个真正随身携带的数字终端，我们除了利用手机打电话、发信息外，往往让他帮助我们记录文字性的信息。PDA有较大的屏幕和手写输入的功能，而手机上的记事功能有限，记录的内容很简单。可以说利用手机记录信息是一种被视为理所应当的功能，也造就了一个一系列的应用——将手机作为随时随地的信息收集器。不难设想此类应用会用一定的市场，我们今天选择的Note记事本项目，正是此类应用的单机版的原形。

 

Note是很多手机的内建应用程序，一般叫做记事本或便签，说明这是一个非常常用的服务。也许朋友们可能认为开发一个已有的程序没有挑战性。是的，在开发上最忌讳的就是重作车轮，但对于教学则可两说着。毕竟一个简单的原型程序不会让我们陷入太多的细节，我的主旨是向大家介绍MVC模式的应用方法。

 

Note为手机用户提供记录一些简短信息的功能，用户可以添加记录，打开浏览记录，并可以随时修改已经保存在手机上的记录，当然也可以删除它们。就好象Windows下的记事本一样，只不过多了管理的功能。

 

 

首先设想一下谁在使用这个程序：手机用户。好，我们以后就称这个参与者为用户（user）。

然后设想一下，用户都利用我们的NOTE（中文我们叫做记录好了）干些什么呢？很显然，用户可以添加新的记录，浏览他添加的记录，修改他所添加的记录，并且他还可以删除记录。一条记录应该简单的包括用户对记录起的名字，记录的创建或修改时间，以及最重要的记录的内容。

 

一般的情况开发人员是很反感这种文字性的描述的，往往是因为开发人员习惯于对待硬梆梆的PC机，而不愿意去面对客户，收集这种需求。其实文字性的东西，既是一个对系统的概述，又是我们发现开发要素的土壤。试想如果你的软件要发布了，你却无法组织起语言让用户恰当的理解软件的功能与使用对象，是多么的让人烦恼。

 

精练用户的需求（其实是我的教学需求哈哈）。很显然添加记录与修改记录同属于对记录进行编辑操作，就叫做编辑记录用例（NoteEdit）好了。浏览记录也是一个很明显的用例，就叫做浏览用例（Notepad）。删除是对记录进行的一种管理，叫做管理记录用例（NoteManager）。到此，我们已发现并精练了三个主要用例，还不错，系统正一步步变的清晰。在这里提醒大家，这个阶段是站在客户的观点（这里是用户的观点）想问题的，你的工作是发现并系统化客户的想法，不必站在开发者的角度思考任何细节。

 

So，let ‘go。

事件流1：

1） 显示用户Note的内容

2） 用户编辑内容

3） 用户放弃修改，note内容不变，正常退出

 

事件流2：

1） 显示用户Note的内容

2） 用户编辑内容

3） 用户save，退回主菜单

 

事件流3：

1） 显示用户Note的内容

2） 用户编辑内容

3） 用户save As，提示让用户输入新的文件名

4） Save，退回主菜单

 

事件流1：

1） 显示用户的Note的标题、创建时间、内容

2） 用户选择退出，返回主菜单

 

事件流2：

1） 显示用户的Note的标题、创建时间、内容

2） 用户显示编辑，转向编辑用例

 

事件流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列表

 

三个用例的事件流一经被分析出来了，很显然应该在第一次迭代全部完成。

 

首先是实体类（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吗，有可能看懂：）

 

开始后的画面:（管理用例）

新建后的画面：（编辑用例）

按下save，输入title名字

更新显示：

选择你喜欢的浏览，比如标题是easy的记录：（浏览用例）

 

有朋友不愿意公开自己的代码，但是对于java来说，反编译太容易了。你没有什么秘密可言。相对于设计来说，代码是个很细碎的东西。如果有人愿意为你修改代码，共同完善的话，那是打着灯笼也找不到的呀，我用eclipse开发，就是在使用开放源码的结晶呀。当然这是对文章的附加代码而言。真正的项目如果开源一定要在GPL下进行。谁也不想再出现divx那样的事了。转载的朋友，再说一遍免费不但等于 not copyright。