Aexi(3)

Aexi的最新進度來了.今天進行了一些初步的設計

具體有哪些類請看圖

結構的設計基本與《DP》中提到的一致，但是又有一些不同。

 

首先是文檔的物理結構,我們應該怎麼樣表示一個文檔呢?不知道是否是我想的比較簡單,還是這個問題確實比較簡單,《DP》中將文檔的物理結構分爲基本子圖元、行、列.但是依筆者愚見,文檔的物理結構應該就是一組基本Glyph的直接集合.而至於分行,分列,分頁等工作,應該是封裝了格式化算法的Composition的職責.那麼文檔的物理結構中確實有行和列的結構,那麼又該怎麼體現呢?筆者覺得,Glyph圖元中用對應的相關轉義字符應該可以完全解決,比如,當表示一個新行時,”\n”這樣的換行符應該完全可以表示一個新的行.至於頁,那也不是由文檔的物理結構決定的,而是應該由具體的設置,比如頁的大小決定的.用戶設置每一頁的大小,然後格式化類將Glyph集合中的元素添加到新的頂層結構中,並將最上層讓composition持有.

不知這樣的設計是否有什麼缺陷,至少現在看不出來.先這麼寫着,讓時間來檢驗吧.

其他的地方就是定義了一個GlyphImpl類,實現了Glyph接口,並擴充了一個Frame字段,Frame同樣也是一個定義的class,用來描述每個Glyph的大小以及位置信息.

另外,同樣還定義了一個GlyphImplGroup類,看到這樣的命名風格,各位讀者應該會覺得很熟悉.對的GlyphImpl和GlyphImplGroup的關係,就類似於Android中View和ViewGroup的關係, GlyphImplGroup繼承自GlyphImpl.爲什麼要這麼設計呢?因爲按照書中的設計,給諸如character這樣的基本Glyph實現類添加insert(),remove()這樣的方法總覺得有點怪怪的.於是就修改了.

下面上GlyphImplGroup的實現代碼.

public class GlyphImplGroup extends GlyphImpl {
    protected List<GlyphImpl> children;
    public void insert(GlyphImpl glyph,int index) {
        children.add(index,glyph);
    }

    public GlyphImplGroup() {
        children = new ArrayList<GlyphImpl>();
    }
    public List<GlyphImpl> getChildren() {
        return children;
    }

    public void append(GlyphImpl glyph) {
        children.add(glyph);
    }

    public void remove(int index) {
        children.remove(index);
    }

    @Override
    public void drawMe(Graphics g) {
        for (Glyph glyph : children) {
            glyph.drawMe(g);
        }
    }
}

可以看到GlyphImplGroup類直接實現了drawMe()方法,並遍歷了children集合中的每一個元素,依次調用了他們的drawMe()方法.

當然,在調用這一方法之前需要注意的必須調用,compositor的compose()方法進行格式化,格式化時遍歷Document對象,並對每個Glyph對象的frame進行賦值,這樣在調用drawMe()方法時,就可以根據frame對象畫出每個Glyph對象了.

上截圖一張:

     Caret對象的位置和文字的位置還沒有對應起來,這是因爲還沒有把Caret納入到Glyph的體系中,這個工作留到明天完成.

     最後補充一點,怎麼接受鍵盤輸入呢.考慮到在應用運行過程中,需要處理很多鍵盤鼠標的事件,所以定義一個controller類專門處理這些事件.

     每當接受到鍵盤輸入,就將接受到的字符調用composition的insert()方法append到composition持有的Document對象的相應位置.並調用compositor的compose()方法再次對Document對象進行格式化,格式化完成後申請重繪.

        最最後再補充一點,關於文檔結構的優化,其實筆者覺得可以在增加一個名字叫string的Glyph對象.當文檔結構每一次改變後,將多個連續的、具有統一樣式的character合併爲同一個對象.讀者觀察本篇文檔即可發現,這樣的情況還是比較普遍的.當文檔的字數較多時,或許可以節省一定的內存.