作者：jeru
email: jeru@163.net
日期：7/13/2001 5:48:41 PM
二, 結構型模式 (Structural Patterns)
這一類的模式關心類和對象之間怎么組織起來形成大的結構. 主要使用繼承來組織接口或實現. 

我們再接著思考一下, 用戶之間應該有所區別, 有 Guest 用戶, 可以讓他來看一看, 但不能發貼子, 正式用戶可以發貼子, 查看自己的個人信息, 版面管理者(稱之為版主)應該可以控制貼子, 比如加上適當的標記, 收入精華區, 甚至刪除貼子等等, 而系統管理者應該具有更高的權限, 比如開新的版面, 刪除用戶等操作. 怎么實現這個功能呢? 我們知道, Jive 中所有實際的操作都是由 database 目錄下的類所實現的,如果把權限控制加到數據庫這一層的話, 這一層不但臃腫, 而且寫好以后, 如果要改的話, 需要修改的地方很多, 還容易出錯, 所以可以在這一層之上再加一層, 單獨進行權限控制. 這樣就把 "該不該做" 和 "怎么做" 分割開來, 利于以后修改. 其實這也是面象對象的一個思想 -- 一個對象不要負擔太多的責任. 這種方法在設計模式中稱為 Proxy (代理) 模式. 好比生產廠家和代理商的關系. (當然, 在 Jive 中這個比喻不太合適). Proxy 的目的就是給另一個對象提供一個代理來控制對它的訪問. 
Proxy 模式一直貫穿 Jive 的始終, 幾乎所涉及到的對象都需要. 其結構如圖 2所示. 
從前面已經知道, ForumFactory 是整個系統的開始. 再來看看 ForumFactory 的代碼: From ForumFactory.java

ForumFactory.getInstance() 的最后:

        ForumFactoryProxy proxy = new ForumFactoryProxy(
                                    factory,
                                    authorization,
                                    factory.getPermissions(authorization)
                                  );
        return proxy;
 

前面得到的 factory 是 DbForumFactory 的實例, 這里把這個實例又用ForumFactoryProxy 封裝起來. 最后返回一個 ForumFactoryProxy 的實例. 也就是說 jsp skin 的設計者所用的 ForumFactory 實際上是 ForumFactoryProxy. 接著看看 ForumFactoryProxy 里發生了什么事, 那一個小片段做例子: 
其構造函數中的 Factory 就是一個 DbForumFactory 的實例, 由它來做具體的工作. Authorization 可以認為是一個認證過的當前用戶(指實際的瀏覽器的使用者),ForumPermissions 可以認為是當前用戶的權限. 
    public Forum createForum(String name, String description)
            throws UnauthorizedException
    {
        //這里就對權限進行了檢查, 具有系統管理員權限, 則可以進行相應的操作,
        //否則拋出異常.

        if (permissions.get(ForumPermissions.SYSTEM_ADMIN)) {
            Forum newForum = factory.createForum(name, description);
            return new ForumProxy(newForum, authorization, permissions);
        }
        else {
            throw new UnauthorizedException();
        }
    }

    public Forum getForum(int ID) throws ForumNotFoundException,
            UnauthorizedException
    {
        Forum forum = factory.getForum(ID);
        ForumPermissions forumPermissions = forum.getPermissions(authorization);
        //Create a new permissions object with the combination of the
        //permissions of this object and tempPermissions.
        ForumPermissions newPermissions =
                new ForumPermissions(permissions, forumPermissions);
        //Check and see if the user has READ permissions. If not, throw an
        //an UnauthorizedException.
        if (!(
            newPermissions.get(ForumPermissions.READ) ||
            newPermissions.get(ForumPermissions.FORUM_ADMIN) ||
            newPermissions.get(ForumPermissions.SYSTEM_ADMIN)
            ))
        {
            throw new UnauthorizedException();
        }

        // 同上所述.
        // 這里得到的 forum, 是一個 DbForum 的實例, 跟 ForumFactory 一樣,
        // 返回一個封裝過的代理對象, 來對 forum 進行權限控制.

        return new ForumProxy(forum, authorization, newPermissions);
    }
 


其他所有的對象都是類似的. 這里就不再贅述. 

三, 行為型模式 (Behavioral Patterns)
這一類的模式關心的是算法以及對象之間的任務分配. 它所描述的不僅僅是對象或類的設計模式, 還有它們之間的通訊模式. 

1, 下來看看怎么從一個 Forum 中得到一些 Thread. 當然這里要涉及到數據庫, 我們先設計一個最簡單的數據庫表, 表名: thread, 字段 ThreadID int, ForumID int, 其他內容我們不關心. 然后比如 Forum 中的一個方法, getThreads() 來返回當前 Forum 所有的 Thread. 然后就可以這樣做:            public ForumThread[] getThreads()
           {
                1, 從數據庫里面查詢, 取出所有的 ThreadID,
                2, 根據 ThreadID 構造 ForumThread 對象,
                3, 返回一個數組.
           }
 

這樣做最省事, 最簡單了, 但好不好呢? 還得看需求, 比如我要求根據時間排序,就還得修改這個方法, 也就是說需要修改 DbForum 對象. 那為什么不把取 Thread 這個操作單獨拿出來呢? 這樣的好處就是功能獨立化, 使 DbForum 更簡單, 符合前面我們所提到的不要讓對象負擔太多的責任這個原則. 也許你會說, 如果要修改的話, 不是都得修改嗎? 放哪里是一樣的, 這樣沒錯, 但只限于很小的系統, 如果系統一大, 那么就可能做 DbForum 中的簡單查詢和一些比較復雜的查詢的程序員就不是一個人, 這樣牽扯到需要改動的地方較多, 但分離以后, 只需要一個人改很少的地方就可以完成. 回過頭來再看看問題, 這里要返回一群 ForumThread 對象, 而且它們之間還可能有一定的先后關系, 怎么來做這個工作呢? Iterator 設計模式是一個合適的選擇. Iterator 模式提供了一個連續訪問一大群對象的方法, 而不需要知道它們的表現形式, 比如按什么方式排序等等. 
好了, 來看看 Jive 的具體實現. 由于 Java 本身已經有這樣的接口, Iterator 接口, 所以只要實現這個接口就可以了.
From DbForum:

    public Iterator threads() {
        return new DbForumIterator(this, factory);
    }


From DbForumIterator:  (做了改動)

public class DbForumIterator implements Iterator {

     public DbForumIterator(...)
     {
        ...
     }

     public boolean hasNext()       //是否還有元素
     {
       ...
     }

     public Object next()      // 得到下一個元素
     {
       ...
     }

     ...

}
 
那么 jsp 中可以這樣訪問:     Iterator threads = aForum.threads();
    while (threads.hasNext())
    {
        ForumThread thread = (ForumThread)threads.next();
        做一些操作.
    }
 
從中可以看出, 通過使用 Iterator 把 Threads 的一些具體細節進行了封裝, 提供統一的接口. Jive 中這個設計模式也是用的非常多, 多個用戶顯示, 多個版面顯示, 多個線索, 多個貼子都需要由它來實現. 

小結:
上面我們一起探討了一下設計模式在 Jive 中的應用情況, 當然只是很簡單, 很膚淺, 也很片面, 不過總算能對設計模式有些認識. 實際上, 設計模式就是吸收許多前人的經驗, 把設計中一些重要的和重復出現的一些模式總結起來, 給出一個系統的命名,給出相應的解釋和評價, 這個工作最先由 4 位軟件大師所做, 他們合寫了一本書 --Design Pattern: Elements of Reusable Object-Oriented Software, 后來, 人們把他們稱為 GoF (Gang Of Four). 

對于設計模式, 可能在我們的實際項目中自覺不自覺地在使用著, 比如 Factory Method 模式, Abstract 模式, Singleton 模式, Iterator 模式, 等等, 只是概念不是非的明確, 設計可能還有不太合理的地方, 處于一種跟著感覺走的狀態, 相信很多有經驗的設計者, 原來沒有接觸設計模式, 一旦接觸以后, 會有一種恍然大悟的想法, 哈, 原來是這么回事. 學習設計模式, 能很好地幫助我們設計, 在相同的問題, 相同的背景下,可以直接使用它, 有的時候不知道該選擇哪種好, 就需對問題進行更深一層的分析, 進行綜合權衡, 對設計模式也要進行更深刻的理解, 才能得到好的結果, 這也是一個進步的過程. 

對于筆者來說, 剛剛接觸設計模式, 有了一點粗淺的理解, 就冒昧寫了這篇算是一點心得的東西, 也是對自己的挑戰, 中間犯的一些錯誤, 還請指正, 謝謝. 

參考文獻:

Design Pattern: Elements of Reusable Object-Oriented Software, 
Jive 源代碼