Jive 中的設計模式 (轉)

Jive 中的設計模式 (轉)[@more@]

Jive 中的設計

馬旋
2001年 5月

摘要:Jive 是一個開放原始碼的論壇專案, 也就是我們所常見的 BBS, 採用了 SUN 公司的 技術, 相比起 這個龐大的體系結構, 其整個的設計思想非常精煉, 適用於中小型網站, 建立自己的論壇. 這篇文章我們就一起來看一看 Jive 中所應用的設計模式(Design Pattern).
關於設計模式, 這篇文章並不詳細解釋, 只是結合 Jive 來看看設計模式在一個實際專案中的應用及其整體的設計思想. 所以在讀這篇文章前, 假設您對設計模式有一個感性的認識, 對其具體應用以及實現方法有些疑問, 並渴望瞭解其思想,並使用過 Jive. 本文將一同來探討這個問題. 為什麼選擇 Jive 而不是選擇一個新的例子重新開始呢? 有以下兩個原因: 1, 我們很多人對 bbs 這樣一個事物比較熟悉,很清楚 bbs 所具有的一些基本功能, 如果自己作為設計者來設計這樣一個 bbs,會怎麼想, 再看看別人是怎麼實現的, 有對比才能明白自己設計上的缺點, 看到別人的優點才能更快地進步. 2, Jive 並不是非常地複雜, 並且包括了一個完整的實現方案, 從底層到高層, 從後端到前端, 都有很好的文件, 這些都能更好地幫助我們理解它.

這裡我們所用的 Jive 的版本採用其開發者作為正式釋出的 1.0 版, 其最新版為 1.21, 對其結構作了少量改動, 主要增加了 jsp tag 的支援, 這種技術不屬於我們的討論範圍, 以後有機會可以共同學習.

Jive 中所使用的設計模式, 對設計模式的三種型別 -- 建立型, 結構型,行為型 -- 都有涉及, 這樣也能比較全面地瞭解設計模式. 我們先來自己設計一下,運用面向的思想, 可以很容易知道, 整個系統主要需要這幾個物件:

Forum　　 --　　一個討論區, 也就是一個版面.
Thread　　--　　一條線索, 也就是有關同一個主題的所有的迴文.
Message　 --　　一條訊息, 也就是一個發的一篇貼子.(以後我們就用"貼子"這個叫法)
User　　　--　　一個使用者, 也就是討論區的使用者.
好了, 我們需要的東西都在了, 它們之間的關係十分複雜, 怎麼把它們組織地很符合我們的思路又能容易擴充呢? 我想大家都有自己的想法了, "我能這麼這麼做","我可以這樣這樣設計", 我們一起來看看 Jive 是怎麼做的. 下面是其整體結構:
|~~~~~~~~~~~~~~~~~~|
| Skin 設計者 |
|__________________|
| |
| | 使用
/
|~~~~~~~~~~~~~~~~~|
| 各種物件的介面 |
|_________________|
| |
| | 被實現
/
|~~~~~~~~~~~~|
| 控制 |
|____________|
| |
| | 控制
/
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
| 對進行操作的各種物件 |
|_____________________________|
| |
| | 取連線
/
|~~~~~~~~~~~~~~~~|
| 資料庫連線池 |
|________________|
(圖 1)



下面是其類的大概的繼承情況:

|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
| Interface A |
|___________________________________|
| |
| implements |
| |
|~~~~~~~~~~~~~~~~~| |
| A | |
|_________________| |
|
|
|~~~~~~~~~~~~~~~~~~|
| Database A |
|__________________|
(圖 2)



好了看到這裡, 如果您對設計模式有了解的話, 從上面所寫的偽名字中, 可以看到一些熟悉的東西. 請讓我做一些解釋. 上面的圖表示的是類的繼承關係, A 代表上面所提到的四種物件, Interface A 表示名為 A 的一個介面, 相信大家對介面都不陌生, 介面在 中有著重要的作用. Proxy A 表示一個名為 ProxyA 的類,實現 A 介面. Database A 表示名為 a 的一個類, 實現 A 介面. 但設計模式並沒有從中體現出來,設計模式所要表現的是怎麼樣更好地組織物件之間的邏輯關係,怎麼樣才能更好地擴充現有的東西而不需要作很大的改動, 而不僅僅是類的繼承.

還有一點需要說明的是, 設計模式總的原則是針對介面, 而不關心其具體實現, 這樣搭起來的是一個架子, 還需要作許多具體的程式設計才能真正的完成系統.

下面, 我們就分別從設計模式的三種型別來看 Jive 使用了其中的哪些.

一, 建立型模式 (Creational Patterns)
這一型別的設計模式, 所要表現的是物件的建立過程及和使用者所使用的物件之間的關係.

Jive 中在 Forum 之上又加了一層, ForumFactory, 來實現對 Forum 的一些控制, 比如建立新的討論區, 刪除一個討論區等等. 這個類實際上是整個系統的入口,jsp 中所做的一切都要從得到這個類的一個例項開始. 它的一些子類和它的關係如下:
|~~~~~~~~~~~~~~~~~|
| ForumFactory | abstract
|_________________|
| |
| extends |
| |
|~~~~~~~~~~~~~~~~~~~~| |~~~~~~~~~~~~~~~~~|
| ForumFactoryProxy | | DbForumFactory |
|____________________| |_________________|

(圖 3)

我們來看一下得到一個 ForumFactory 例項的過程:
FactoryForum factory = ForumFactory.getInstance(aAuthorization);就得到了 ForumFactory 的例項, 這個終端使用者(skin 設計人員)所使用的是它的子類 ForumFactoryProxy 的例項, (其中涉及到另一個模式, 後面將會提到), 但實際上真正在做實際工作的是 DbForumFactory 或者是一個指定的類的例項, 相關程式碼如下:

From ForumFactory.java

private static String className = "com.cools.forum.database.DbForumFaactory";
// 系統預設的 ForumFactory 的一個具體的子類.

private static ForumFactory factory = null;

ForumFactory.getInstance()

String classNameProp = PropertyManager.getProperty("ForumFactory.className")
// 可以透過配製來選擇其他的具體的子類.

if (classNameProp != null) {
className = classNameProp;
}
try {
//Load the class and create an instance.
Class c = Class.forName(className);
factory = (ForumFactory)c.newInstance();
}
catch (Exception e) {
System.err.println("Failed to load ForumFactory class "
+ className + ". Jive cannot function normally.");
e.printStackTrace();
return null;
}


它使用的是 Abstract Factory (抽象工廠)設計模式. 給使用者一個使用一系列相關物件的介面, 而不需要指定其具體的類. 也就是說, skin 設計人員寫的 jsp 中不應該出現new DbForumFactory 之類的語句. Jive 中 AuthorizationFactory 也使用了這個設計模式


Jive 中有一個很不錯的想法, 就是對貼子的內容和標題可以進行過濾, 比如過濾 html過濾一些髒話, 對附加的程式碼進行高亮顯示, 轉換連結等等. 如果我要實現這樣的功能, 有有下幾種方法: (1) 在 Message.getBody() getSubject() 中進行控制, (2) 在 Thread 中得得Message 後進行轉換. 還需要考慮的問題是這些過濾的操作必須能夠很方便地新增刪除. 不不的目標所用的設計方法是不一樣的, Jive 是這樣做的: 以版面為主, 把這些過濾器看作是鞍婷的屬性, 過濾器只對其所屬的版面有效, 所以 Jive 中使用了 (2), 這並不是主要的, 重要要是這些過濾器該怎麼來組織. 我們先來看看需求: 能動態新增刪除, 功能類似, 貼子的顯示示其具體怎麼建立, 如何表現無關. 似乎目標只有一個 -- (原型) 設計模式. 看看Jive 的具體實現. |~~~~~~~~~~~~~~~~~~~~|
| ForumMessage |
|____________________|
|
| implements
|
|~~~~~~~~~~~~~~~~| Prototype |~~~~~~~~~~~~~~~~~~~~~|
| ForumThread |-----------&gt | ForumMessageFilter |
|----------------| |---------------------|
| getMessage() o | | clone() |
|______________|_| |_____________________|
| / |
|~~~~~~~~~~~~~~~~| |~~~~~~~~~~~~~~~| |~~~~~~~~~~~~~|
| aFilter.clone()| | HighlightCode | | HTML |
|________________| |---------------| |-------------| ......
| clone() o | | clone() o |
|___________|___| |___________|_|
| |
|~~~~~~~~~~~~~~~| |~~~~~~~~~~~~~~~|
| 返回一個例項 | | 返回一個例項 |
|_______________| |_______________|

(圖 4)

上圖作了少許的簡化. Jive 用的時候是把這些過濾器存在資料庫中, 可以動態設定屬性, 比較方便. 來看一些程式碼:

From: DbForumThread.java

public ForumMessage getMessage(int messageID)
throws ForumMessageNotFoundException
{
ForumMessage message = factory.getMessage(messageID);

//Apply filters to message.

message = forum.applyFilters(message);

//透過 Forum 來實現, 因為 Filter 是 Forum 的屬性,
//Thread 只能透過 Forum 的介面來訪問.

return message;
}

From: DbForum.java

public ForumMessage applyFilters(ForumMessage message) {

for (int i=0; i < filters.length; i++) {
message = filters[i].clone(message);
}

//可能會有多個過濾器, 依次來操作.

return message;
}


二, 結構型模式 (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.getPessions(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 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