Jive 中的設計模式
Jive 中的設計模式 (Design Pattern)
關鍵字: Jive, Design Pattern.
時間: 2001-4-1
摘要:
Jive 是一個開放原始碼的論壇專案, 也就是我們所常見的 BBS, 採用了 SUN
公司的 JSP 技術, 相比起 j2ee 這個龐大的體系結構, 其整個的設計思想非常
精煉, 適用於中小型網站, 建立自己的論壇系統. 這篇文章我們就一起來看一看
Jive 中所應用的設計模式(Design Pattern).
正文:
關於設計模式, 這篇文章並不詳細解釋, 只是結合 Jive 來看看設計模式在一
個實際專案中的應用及其整體的設計思想. 所以在讀這篇文章前, 假設您對設計模
式有一個感性的認識, 對其具體應用以及實現方法有些疑問, 並渴望瞭解其思想,
並使用過 Jive. 本文將一同來探討這個問題. 為什麼選擇 Jive 而不是選擇一個新的
例子重新開始呢? 有以下兩個原因: 1, 我們很多人對 bbs 這樣一個事物比較熟悉,
很清楚 bbs 所具有的一些基本功能, 如果自己作為設計者來設計這樣一個 web bbs,
會怎麼想, 再看看別人是怎麼實現的, 有對比才能明白自己設計上的缺點, 看到別人
的優點才能更快地進步. 2, Jive 並不是非常地複雜, 並且包括了一個完整的實現方
案, 從底層到高層, 從後端到前端, 都有很好的文件, 這些都能更好地幫助我們理解
它.
這裡我們所用的 Jive 的版本採用其開發者作為正式釋出的 1.0 版, 其最新版
為 1.21, 對其結構作了少量改動, 主要增加了 jsp tag 的支援, 這種技術不屬於我
們的討論範圍, 以後有機會可以共同學習.
Jive 中所使用的設計模式, 對設計模式的三種型別 -- 建立型, 結構型,
行為型 -- 都有涉及, 這樣也能比較全面地瞭解設計模式. 我們先來自己設計一下,
運用物件導向的思想, 可以很容易知道, 整個系統主要需要這幾個物件:
1, Forum -- 一個討論區, 也就是一個版面.
2, Thread -- 一條線索, 也就是有關同一個主題的所有的迴文.
3, Message -- 一條訊息, 也就是一個使用者發的一篇貼子.
(以後我們就用"貼子"這個叫法)
4, User -- 一個使用者, 也就是討論區的使用者.
好了, 我們需要的東西都在了, 它們之間的關係十分複雜, 怎麼把它們組織地
很符合我們的思路又能容易擴充呢? 我想大家都有自己的想法了, "我能這麼這麼做",
"我可以這樣這樣設計", 我們一起來看看 Jive 是怎麼做的. 下面是其整體結構:
|~~~~~~~~~~~~~~~~~~|
| Skin 設計者 |
|__________________|
| |
| | 使用
\ /
|~~~~~~~~~~~~~~~~~|
| 各種物件的介面 |
|_________________|
| |
| | 被實現
\ /
|~~~~~~~~~~~~|
| 許可權控制 |
|____________|
| |
| | 控制
\ /
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
| 對資料庫進行操作的各種物件 |
|_____________________________|
| |
| | 取連線
\ /
|~~~~~~~~~~~~~~~~|
| 資料庫連線池 |
|________________|
(圖 1)
下面是其類的大概的繼承情況:
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
| Interface A |
|___________________________________|
| |
| implements |
| |
|~~~~~~~~~~~~~~~~~| |
| Proxy A | |
|_________________| |
|
|
|~~~~~~~~~~~~~~~~~~|
| Database A |
|__________________|
(圖 2)
好了看到這裡, 如果您對設計模式有了解的話, 從上面所寫的偽名字中, 可以
看到一些熟悉的東西. 請讓我做一些解釋. 上面的圖表示的是類的繼承關係, A 代
表上面所提到的四種物件, Interface A 表示名為 A 的一個介面, 相信大家對介面
都不陌生, 介面在 java 中有著重要的作用. Proxy A 表示一個名為 ProxyA 的類,
實現 A 介面. Database A 表示名為 DbA 的一個類, 實現 A 介面. 但設計模式並
沒有從中體現出來,設計模式所要表現的是怎麼樣更好地組織物件之間的邏輯關係,
怎麼樣才能更好地擴充現有的東西而不需要作很大的改動, 而不僅僅是類的繼承.
還有一點需要說明的是, 設計模式總的原則是針對介面程式設計, 而不關心其具體
實現, 這樣搭起來的是一個架子, 還需要作許多具體的程式設計才能真正的完成系統.
下面, 我們就分別從設計模式的三種型別來看 Jive 使用了其中的哪些.
一, 建立型模式 (Creational Patterns)
這一型別的設計模式, 所要表現的是物件的建立過程及和使用者所使用的物件之間
的關係.
1, 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.coolservlets.forum.database.DbForumFactory";
// 系統預設的 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 也使用了這個設計模式.
2, Jive 中有一個很不錯的想法, 就是對貼子的內容和標題可以進行過濾, 比如過濾 html,
過濾一些髒話, 對附加的程式碼進行高亮顯示, 轉換連結等等. 如果我要實現這樣的功能, 有以
下幾種方法: (1) 在 Message.getBody() getSubject() 中進行控制, (2) 在 Thread 中得到
Message 後進行轉換. 還需要考慮的問題是這些過濾的操作必須能夠很方便地新增刪除. 不同
的目標所用的設計方法是不一樣的, Jive 是這樣做的: 以版面為主, 把這些過濾器看作是版面
的屬性, 過濾器只對其所屬的版面有效, 所以 Jive 中使用了 (2), 這並不是主要的, 重要的
是這些過濾器該怎麼來組織. 我們先來看看需求: 能動態新增刪除, 功能類似, 貼子的顯示和
其具體怎麼建立, 如何表現無關. 似乎目標只有一個 -- Prototype(原型) 設計模式. 看看
Jive 的具體實現.
|~~~~~~~~~~~~~~~~~~~~|
| ForumMessage |
|____________________|
|
| implements
|
|~~~~~~~~~~~~~~~~| Prototype |~~~~~~~~~~~~~~~~~~~~~|
| ForumThread |-----------> | 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.clone(message);
}
//可能會有多個過濾器, 依次來操作.
return message;
}
二, 結構型模式 (Structural Patterns)
這一類的模式關心類和物件之間怎麼組織起來形成大的結構. 主要使用繼承來
組織介面或實現.
1, 我們再接著思考一下, 使用者之間應該有所區別, 有 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 模式, 等等, 只是概念不是非常
的明確, 設計可能還有不太合理的地方, 處於一種跟著感覺走的狀態, 相信很多有經驗
的設計者, 原來沒有接觸設計模式, 一旦接觸以後, 會有一種恍然大悟的想法, 哈, 原
來是這麼回事. 學習設計模式, 能很好地幫助我們設計, 在相同的問題, 相同的背景下,
可以直接使用它, 有的時候不知道該選擇哪種好, 就需對問題進行更深一層的分析, 進行
綜合權衡, 對設計模式也要進行更深刻的理解, 才能得到好的結果, 這也是一個進步的
過程.
對於筆者來說, 剛剛接觸設計模式, 有了一點粗淺的理解, 就冒昧寫了這篇算是一
點心得的東西, 也是對自己的挑戰, 中間犯的一些錯誤, 還請指正, 謝謝.
參考文獻:
2, Jive 原始碼
--
沒有激情，這就是我嗎？
！！！ 不 ！！！
笑天子，應該笑著的，勇敢地面對！
SuperMMX
關鍵字: Jive, Design Pattern.
時間: 2001-4-1
摘要:
Jive 是一個開放原始碼的論壇專案, 也就是我們所常見的 BBS, 採用了 SUN
公司的 JSP 技術, 相比起 j2ee 這個龐大的體系結構, 其整個的設計思想非常
精煉, 適用於中小型網站, 建立自己的論壇系統. 這篇文章我們就一起來看一看
Jive 中所應用的設計模式(Design Pattern).
正文:
關於設計模式, 這篇文章並不詳細解釋, 只是結合 Jive 來看看設計模式在一
個實際專案中的應用及其整體的設計思想. 所以在讀這篇文章前, 假設您對設計模
式有一個感性的認識, 對其具體應用以及實現方法有些疑問, 並渴望瞭解其思想,
並使用過 Jive. 本文將一同來探討這個問題. 為什麼選擇 Jive 而不是選擇一個新的
例子重新開始呢? 有以下兩個原因: 1, 我們很多人對 bbs 這樣一個事物比較熟悉,
很清楚 bbs 所具有的一些基本功能, 如果自己作為設計者來設計這樣一個 web bbs,
會怎麼想, 再看看別人是怎麼實現的, 有對比才能明白自己設計上的缺點, 看到別人
的優點才能更快地進步. 2, Jive 並不是非常地複雜, 並且包括了一個完整的實現方
案, 從底層到高層, 從後端到前端, 都有很好的文件, 這些都能更好地幫助我們理解
它.
這裡我們所用的 Jive 的版本採用其開發者作為正式釋出的 1.0 版, 其最新版
為 1.21, 對其結構作了少量改動, 主要增加了 jsp tag 的支援, 這種技術不屬於我
們的討論範圍, 以後有機會可以共同學習.
Jive 中所使用的設計模式, 對設計模式的三種型別 -- 建立型, 結構型,
行為型 -- 都有涉及, 這樣也能比較全面地瞭解設計模式. 我們先來自己設計一下,
運用物件導向的思想, 可以很容易知道, 整個系統主要需要這幾個物件:
1, Forum -- 一個討論區, 也就是一個版面.
2, Thread -- 一條線索, 也就是有關同一個主題的所有的迴文.
3, Message -- 一條訊息, 也就是一個使用者發的一篇貼子.
(以後我們就用"貼子"這個叫法)
4, User -- 一個使用者, 也就是討論區的使用者.
好了, 我們需要的東西都在了, 它們之間的關係十分複雜, 怎麼把它們組織地
很符合我們的思路又能容易擴充呢? 我想大家都有自己的想法了, "我能這麼這麼做",
"我可以這樣這樣設計", 我們一起來看看 Jive 是怎麼做的. 下面是其整體結構:
|~~~~~~~~~~~~~~~~~~|
| Skin 設計者 |
|__________________|
| |
| | 使用
\ /
|~~~~~~~~~~~~~~~~~|
| 各種物件的介面 |
|_________________|
| |
| | 被實現
\ /
|~~~~~~~~~~~~|
| 許可權控制 |
|____________|
| |
| | 控制
\ /
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
| 對資料庫進行操作的各種物件 |
|_____________________________|
| |
| | 取連線
\ /
|~~~~~~~~~~~~~~~~|
| 資料庫連線池 |
|________________|
(圖 1)
下面是其類的大概的繼承情況:
|~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
| Interface A |
|___________________________________|
| |
| implements |
| |
|~~~~~~~~~~~~~~~~~| |
| Proxy A | |
|_________________| |
|
|
|~~~~~~~~~~~~~~~~~~|
| Database A |
|__________________|
(圖 2)
好了看到這裡, 如果您對設計模式有了解的話, 從上面所寫的偽名字中, 可以
看到一些熟悉的東西. 請讓我做一些解釋. 上面的圖表示的是類的繼承關係, A 代
表上面所提到的四種物件, Interface A 表示名為 A 的一個介面, 相信大家對介面
都不陌生, 介面在 java 中有著重要的作用. Proxy A 表示一個名為 ProxyA 的類,
實現 A 介面. Database A 表示名為 DbA 的一個類, 實現 A 介面. 但設計模式並
沒有從中體現出來,設計模式所要表現的是怎麼樣更好地組織物件之間的邏輯關係,
怎麼樣才能更好地擴充現有的東西而不需要作很大的改動, 而不僅僅是類的繼承.
還有一點需要說明的是, 設計模式總的原則是針對介面程式設計, 而不關心其具體
實現, 這樣搭起來的是一個架子, 還需要作許多具體的程式設計才能真正的完成系統.
下面, 我們就分別從設計模式的三種型別來看 Jive 使用了其中的哪些.
一, 建立型模式 (Creational Patterns)
這一型別的設計模式, 所要表現的是物件的建立過程及和使用者所使用的物件之間
的關係.
1, 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.coolservlets.forum.database.DbForumFactory";
// 系統預設的 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 也使用了這個設計模式.
2, Jive 中有一個很不錯的想法, 就是對貼子的內容和標題可以進行過濾, 比如過濾 html,
過濾一些髒話, 對附加的程式碼進行高亮顯示, 轉換連結等等. 如果我要實現這樣的功能, 有以
下幾種方法: (1) 在 Message.getBody() getSubject() 中進行控制, (2) 在 Thread 中得到
Message 後進行轉換. 還需要考慮的問題是這些過濾的操作必須能夠很方便地新增刪除. 不同
的目標所用的設計方法是不一樣的, Jive 是這樣做的: 以版面為主, 把這些過濾器看作是版面
的屬性, 過濾器只對其所屬的版面有效, 所以 Jive 中使用了 (2), 這並不是主要的, 重要的
是這些過濾器該怎麼來組織. 我們先來看看需求: 能動態新增刪除, 功能類似, 貼子的顯示和
其具體怎麼建立, 如何表現無關. 似乎目標只有一個 -- Prototype(原型) 設計模式. 看看
Jive 的具體實現.
|~~~~~~~~~~~~~~~~~~~~|
| ForumMessage |
|____________________|
|
| implements
|
|~~~~~~~~~~~~~~~~| Prototype |~~~~~~~~~~~~~~~~~~~~~|
| ForumThread |-----------> | 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.clone(message);
}
//可能會有多個過濾器, 依次來操作.
return message;
}
二, 結構型模式 (Structural Patterns)
這一類的模式關心類和物件之間怎麼組織起來形成大的結構. 主要使用繼承來
組織介面或實現.
1, 我們再接著思考一下, 使用者之間應該有所區別, 有 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 模式, 等等, 只是概念不是非常
的明確, 設計可能還有不太合理的地方, 處於一種跟著感覺走的狀態, 相信很多有經驗
的設計者, 原來沒有接觸設計模式, 一旦接觸以後, 會有一種恍然大悟的想法, 哈, 原
來是這麼回事. 學習設計模式, 能很好地幫助我們設計, 在相同的問題, 相同的背景下,
可以直接使用它, 有的時候不知道該選擇哪種好, 就需對問題進行更深一層的分析, 進行
綜合權衡, 對設計模式也要進行更深刻的理解, 才能得到好的結果, 這也是一個進步的
過程.
對於筆者來說, 剛剛接觸設計模式, 有了一點粗淺的理解, 就冒昧寫了這篇算是一
點心得的東西, 也是對自己的挑戰, 中間犯的一些錯誤, 還請指正, 謝謝.
參考文獻:
2, Jive 原始碼
--
沒有激情，這就是我嗎？
！！！ 不 ！！！
笑天子，應該笑著的，勇敢地面對！
SuperMMX
相關文章
- Jive 中的設計模式 (轉)設計模式
- Jive中的設計模式問題設計模式
- 學習設計模式和jive的問題設計模式
- 請斑竹及眾高手：關於EJB，同時使用JIVE中的設計模式。。。設計模式
- 【設計模式】漢堡中的設計模式——策略模式設計模式
- 【設計模式】漢堡中的設計模式——觀察者模式設計模式
- 設計模式中的觀察者模式設計模式
- Ruby中的設計模式設計模式
- php中的設計模式PHP設計模式
- javascript中的設計模式JavaScript設計模式
- Mybatis中的設計模式MyBatis設計模式
- PHP 中的設計模式PHP設計模式
- PHP 實戰之設計模式：PHP 中的設計模式PHP設計模式
- 設計模式（三）Animation中的策略模式設計模式
- OO設計模式中的工廠模式設計模式
- 介面設計中的“黑暗模式”模式
- 理解JavaScript中的設計模式JavaScript設計模式
- JSF中的設計模式JS設計模式
- Android 中的設計模式：觀察者模式Android設計模式
- 設計模式（七）Android中的代理模式設計模式Android
- 原始碼中的設計模式--模板方法模式原始碼設計模式
- 原始碼中的設計模式--工廠模式原始碼設計模式
- Java中的設計模式（一）：觀察者模式Java設計模式
- 設計模式 - ASM 中的訪問者模式設計模式ASM
- 設計模式應用場景之Model設計中可以用到的設計模式設計模式
- PHP 中的設計模式詳解PHP設計模式
- 設計模式中類的關係設計模式
- iOS中的單例設計模式iOS單例設計模式
- 設計模式中的那些原則設計模式
- Java中的設計模式詳解Java設計模式
- 設計模式在 TypeScript 中的應用 – 策略模式設計模式TypeScript
- 原始碼中的設計模式--裝飾器模式原始碼設計模式
- 【設計模式】設計模式的分類設計模式
- Java併發程式設計中的設計模式解析(一)Java程式設計設計模式
- javascript中的設計模式之釋出-訂閱模式JavaScript設計模式
- 設計模式（八）Context中的裝飾者模式設計模式Context
- Python 中的設計模式詳解之：策略模式Python設計模式
- Laravel 中設計模式的實戰分享Laravel設計模式