又是好久都沒有發佈新的博客了.從今天開始要提高更新博客的頻率了,那麼現在開始的博客都寫一些什麼呢?筆者準備寫一個稍微大一點的項目,並在項目的每一個關鍵階段將各個過程記錄下來.
那麼到底是什麼樣的一個項目呢?
我給這個項目取名叫Aexi.是的,相信看過《Design Pattern》這本書的朋友都應該知道了，這個名字來自於《DP》這本書的第二章中的對設計模式綜合運用的一個實例——Lexi.筆者準備將他使用java語言實現一遍,並實現跨平臺.當然這種跨平臺不是完全的write once,run anywhere.而是在儘可能改動少代碼的情況下實現對多種設備的支持,這其中還應當包含對移動設備的支持.爲了達到這種需求,那麼就要求它對設備的視感標準的依賴應當降低到儘可能的低.所以如果它有一個具體可見的Frame顯然是不合適的,適配各個平臺的Frame將是一個巨大的工程,所以筆者希望它應該就是一塊簡單的白板,或者說它什麼都沒有,將與具體界面相關的代碼去除,抽象成一個框架提供給各個程序員們調用,他應當具有足夠的開放性以及拓展性來適應不同程序員的不同需求,當基礎框架的功能不能滿足應用層的程序員的具體需求時,它應當有足夠的開放性以供應用層的程序員自如擴展卻儘量少的影響到Framework源碼.在進行博客的分析時,筆者會儘可能的複習設計模式相關知識,與讀者共同進步.
在windows上,它應該是這樣的
在Android設備上的形態
iOS設備不支持java,所以該框架無法適配到iOS設備上.
既然已經明確的項目的具體形態那麼下面對這個項目的需求做一個簡單的介紹,其中的部分內容與《DP》相同,當然也會有相當一部分的擴充內容.因爲有前輩已經寫過,所以嚴肅的需求分析筆者就不寫了,簡單易懂的需求分析如下:
1. 多視感標準:Aexi應當是跨平臺的,在不同的平臺上,它的樣子應當是不一樣的,並且在不同的平臺上進行適配時,應當共享大部分代碼,進行的改動是極小的.
2. 支持多窗口系統:不同的視感標準是在不同的平臺上實現的,因此Aexi的顯示必須與窗口系統無關.
3.用戶操作:用戶通過不同的界面控制Aexi,包括按鈕和下拉菜單,以及底部欄(移動設備)等其他應用層程序員自定義的界面。這裏要求我們對用戶的操作要做到很好的封裝,並且還要支持撤銷的操作.
4.文本分析:Aexi應該支持多樣化的文本分析功能,包括諸如拼寫檢查、字數統計、文本搜索替換.並應該做到當應用層程序員自定義一些分析功能時,儘可能的減少代碼修改並方便擴充.
5.數學公式輸入:Aexi應該支持數學公式輸入.類似這種變化較大的功能,應該做到可擴充,當應用層程序員希望插入一些可編輯的特殊結構時,應該在框架搭建的體系內輕鬆實現插件化開發.
6.序列化:用戶在Aexi上編輯的文檔應當可以很輕鬆的序列化爲各種常見的格式以便於用戶長久的保存,並且這種序列化的格式也會是可擴充的,其他使用Aexi的程序員們,可以在Aexi的規則下輕鬆的自定義他們希望的格式.這就要求了Aexi的文檔應該和顯示是分離的
以上就是暫時想到的Aexi的需求了.下一篇博客會開始做第一個小功能,文字輸入的光標.