版權聲明：本文同時發表在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。
