轉自 IBM 劉武東，謝謝作者的辛勤勞動！
前言
Jive是一個開放的Java源代碼項目。其目標是建設一個開放結構的，強壯的，易于擴展的基于JSP的論壇。在其設計目標的指導下，其結構設計得非常得好，融合了很多新的觀念，比如Design Pattern，可更換的Skin，可插入Plug等等。詳細解讀其源代碼對于理解這些新的設計上的概念是很有裨益的。如果你對Design Pattern和Java語言有一定的了解，但是還是會時常迷惑于其中的話，不妨研究研究Jive源代碼，一定會對其中的很多概念有更深入的理解。這篇文章源于我的Jive源代碼研究筆記，希望能夠提綱挈領，帶領大家進入到這個美好的世界。當然，如果沒有時間仔細地看源代碼的話，看看這篇文章，我想也是會有一些幫助的。
再開始之前，需要指出的是，Jive中對Design Pattern的應用，并沒有拘禮與GOF書中所給出的實現(xiàn)方法，而是有許多變通的地方。一方面，我想是由于具體的實際需要，另一方面，我想這也是設計觀念進化的結果吧。因而，這些變通的地方，將是我講解的重點。
整體結構概敘
基于一個OO的設計原則：面向接口編程，而不是針對實現(xiàn)編程。Jive在設計的時候，把其大部分的基本對象都設計為接口或者抽象類。在Jive中，基本的接口有Forum，F(xiàn)orumMessage，F(xiàn)orumThread，Group，User，Authorization和Query。我們可以很容易的從這些接口的名字來知道他們的功用，下面的類圖給出了這些類之間的一些靜態(tài)關系：
圖1：Jive整體關系
你可能會有疑問，為什么會都是接口呢？這是基于擴展性考慮的。在Jive給出的實現(xiàn)中，所有的這些接口，F(xiàn)orum，F(xiàn)orumMessage，User等等，都使用數(shù)據(jù)庫來實現(xiàn)的，一條消息，或者一個用戶對應于數(shù)據(jù)庫中的一條消息Jive使用了DbForum，DbForumMessage，DbUser等類來實現(xiàn)這些接口，通過JDBC來操作數(shù)據(jù)庫，使之作為論壇的底層支撐。
然而，有時候，或許我們并不想使用數(shù)據(jù)庫，比如我們想只是使用文件系統(tǒng)來作為論壇的底層支撐，這時候，我們需要做的只是編碼實現(xiàn)了Forum等等接口的諸如FileFroum，F(xiàn)ileForumMessage等對象，然后嵌入Jive中即可，原有的任何代碼都可以不用改變！！！這就是面向接口編程的威力了！
下面來看看具體的設計和編碼。
AbstractFactory模式和可擴展性
如果要實現(xiàn)較好的可擴展性，AbstractFactory模式確實是一件利器。如上面所說，如果要創(chuàng)建的Forum接口的不同實現(xiàn)，而又不想更改代碼的話，就需要用到抽象工廠了。再Jive中，AuthorizationFactory類是一個抽象類，用來創(chuàng)建Authorization對象。這是一個抽象工廠，可以通過不同的子類來創(chuàng)建不同的Authorization對象。這個工廠的實現(xiàn)方法是：
在AuthorizationFactory中使用一個private static變量factory，用來引用具體的抽象工廠的實例：
private static AuthorizationFactory factory = null;
用一個private static的String，來指明具體的抽象工廠的子類類名：
private static String className ="com.coolservlets.forum.database.DbAuthorizationFactory";
然后是用一個private static的loadAuthorizationFactory方法來給這個factory變量賦值，生成具體的抽象工廠類：
private static void loadAuthorizationFactory() {
if (factory == null) {
synchronized(className) {
if (factory == null) {
String classNameProp = PropertyManager.getProperty(
"AuthorizationFactory.className"
);
if (classNameProp != null) {
className = classNameProp;
}
try {
Class c = Class.forName(className);
factory = (AuthorizationFactory)c.newInstance();
}
catch (Exception e) {
System.err.println("Exception loading class: " + e);
e.printStackTrace();
}
}
}
}
}
|
在static的getAuthorization方法返回一個Authorization的過程中，先初始化工廠類factory變量，然后用factory的createAuthorization方法來創(chuàng)建：
public static Authorization getAuthorization(String username,
String password) throws UnauthorizedException
{
loadAuthorizationFactory();
return factory.createAuthorization(username, password);
}
|
不同的子類有不同的createAuthorization方法的實現(xiàn)。比如在DbAuthorizationFactory這個AuthorizationFactory的數(shù)據(jù)庫實現(xiàn)子類中，createAuthorization方法是這樣實現(xiàn)的：
public Authorization createAuthorization(String username, String password)
throws UnauthorizedException
{
if (username == null || password == null) {
throw new UnauthorizedException();
}
password = StringUtils.hash(password);
int userID = 0;
Connection con = null;
PreparedStatement pstmt = null;
try {
con = DbConnectionManager.getConnection();
pstmt = con.prepareStatement(AUTHORIZE);
pstmt.setString(1, username);
pstmt.setString(2, password);
ResultSet rs = pstmt.executeQuery();
if (!rs.next()) {
throw new UnauthorizedException();
}
userID = rs.getInt(1);
}
catch( SQLException sqle ) {
System.err.println("Exception in DbAuthorizationFactory:" + sqle);
sqle.printStackTrace();
throw new UnauthorizedException();
}
finally {
try { pstmt.close(); }
catch (Exception e) { e.printStackTrace(); }
try { con.close(); }
catch (Exception e) { e.printStackTrace(); }
}
return new DbAuthorization(userID);
}
|
在這個類中，可以看到抽象類和具體的子類之間的關系，它們是如何協(xié)作的，又是如何劃分抽象方法和非抽象方法的，這都是值得注意的地方。一般的，抽象方法需要子類來實現(xiàn)，而抽象類中的非抽象方法應該所有子類所能夠共享的，或者可是說，是定義在抽象方法之上的較高層的方法。這確實是一個抽象工廠的好例子！雖然實現(xiàn)的方法已經和GOF中給出的實現(xiàn)相差較遠了，但思想沒變，這兒的實現(xiàn)，也確實是要巧妙的些。
還有就是靜態(tài)方法的使用，使得這個類看起來有些Singleton的意味。這使得對于AbstractFactory的創(chuàng)建變得簡單。
下面的類圖給出了這個AbstractFactory的實現(xiàn)的總體情況：
圖2：AbstractFactory模式的實現(xiàn)類圖
在AuthorizationFactory中定義的其它方法，涉及到具體的如何創(chuàng)建Authorization，都是作為abstract方法出現(xiàn)，具體實現(xiàn)留給子類來完成。
這樣，在需要生成一個Authorization的時候，只需要調用AuthorizationFactory的靜態(tài)方法getAuthorization就可以了，由子類實現(xiàn)了具體的細節(jié)。
其它的，如同上面講到的，在創(chuàng)建Forum的時候用的ForumFactory，具有同上面一樣的實現(xiàn)，這就是模式之所以稱為模式的所在了。
Proxy模式和權限控制
Proxy模式的功能有很多，比如遠程代理，用來給遠程對象提供一個本地代表；虛代理，用來為創(chuàng)建開大開銷的對象提供緩沖，等等。在Jive中使用的是保護代理，為被保護的對象提供權限控制。
我們都知道在一個論壇中，權限的控制是必須的，否則論壇就很可能會被搞得一團糟。Jive中引入Proxy對象，Authorization接口以及權限描敘屬類來提供對論壇的保護。
以ForumFactory為例，一個額外的ForumFactoryProxy來處理權限認證的工作，它為某一個ForumFactory提供了一個代理，保證只有授權的用戶才能夠存取ForumFactory的某些操作。實際上ForumFactory在這兒不僅僅只是一個生成Forum的類的，它更像是一個Forum的管理類。提供了添加，刪除，枚舉等等一系列的功能，而有些功能不是什么樣的人都可以使用的，因而引入了另外的一個代理類來處理權限的問題。
當然，代理類需要繼承ForumFactory，以使方法簽名一致： ForumFactoryProxy extends ForumFactory
在它的構造方法中，就提供了一個ForumFactory對象，這是需要被代理的對象；一個Authorization對象，提供用戶信息；還有一個ForumPermissions，提供認證信息：
public ForumFactoryProxy(ForumFactory factory, Authorization authorization,
ForumPermissions permissions)
{
this.factory = factory;
this.authorization = authorization;
this.permissions = permissions;
}
|
一般的代理過程都是這樣的，在訪問某個方法之前，必須接受權限的檢查，以createForum為例：
public Forum createForum(String name, String description)
throws UnauthorizedException, ForumAlreadyExistsException
{
if (permissions.get(ForumPermissions.SYSTEM_ADMIN)) {
Forum newForum = factory.createForum(name, description);
return new ForumProxy(newForum, authorization, permissions);
}
else {
throw new UnauthorizedException();
}
}
|
下面給出這個模式的類圖：
圖3：Proxy模式的類圖
這個模式的實現(xiàn)基本上和GOF中所給出的實現(xiàn)一致。在Jive中，幾乎所有的接口，F(xiàn)orum，F(xiàn)orumMessage，F(xiàn)orumThread等等，都會有一個相應的Proxy對象來進行權限控制。而在創(chuàng)建具體的對象的時候，都是用相應的Proxy對象來代替原有的對象返回的。例如在ForumFactory的getInstance()方法中需要返回一個Forum的時候，Jive是這樣做的：
public static ForumFactory getInstance(Authorization authorization) {
......
ForumFactoryProxy proxy = new ForumFactoryProxy(factory,authorization, factory.getPermissions(authorization));
return proxy;
}
|
因而，所有被創(chuàng)建的對象實際上都是Proxy對象，抽象工廠保證了沒有權限驗證的對象根本不會客戶所得到，它們只會在Proxy的內部扮演角色，而永遠不會被外部對象所存取，這樣，就從根本上保證了論壇的安全。
Decorator模式和過濾器
一般的在OO設計中，而外功能的添加是通過繼承來實現(xiàn)的，但是繼承有的時候不夠靈活，而且當功能的組合很多的時候，繼承的子類就會成幾何級數(shù)增長，使得類多的難以控制。正是基于這樣的考慮，Decorator模式得以誕生。
Decorator模式相當于封裝了某個特定的操作，當某個對象需要這個操作的時候，加上這個Decorator即可。并且，多個Decorator還可以組合，以提供更多的功能。
在Jive中，Decorator模式應用在一些過濾器（Filter）中。Filter提供對ForumMessage對象內容的重新構造。比如，當一個ForumMessage對象流過一個名為FilterCodeHighlight的過濾器后，存在于消息中的所有Java源代碼文本，會被重新構造為具有語法高亮顯示的消息。在比如，當經過了語法高亮修飾的消息再流過一個名為FilterHtml的過濾器后，消息中的HTML片斷會被注釋可以在HTML內部顯示文本，這樣就防止了用戶輸入了HTML控制標簽后，使得頁面顯示不正常的問題。
Jive中，所有的過濾器繼承于一個抽象類ForumMessageFilter，而ForumMessageFilter又實現(xiàn)了ForumMessage接口。也就是說，每一個過濾器實際上也是一個ForumMessage對象。
ForumMessageFilter中還封裝一個ForumMessage對象。進行過濾的方法很簡單，使用的是getBody()，比如在FilterCodeHighlight這個類中：
public String getBody() {
return highlightCode(message.getBody());
}
|
highlightCode是一個private方法，實施具體的過濾的細節(jié)。getBody()方法實際上是定義在ForumMessage接口中的，當調用過濾器的getBody()方法時，就能夠得到結構重整后的ForumMessage對象了。這個對象可以被其他客戶引用，也可以在傳遞給另外的過濾器，實施進一步的操作。
在實現(xiàn)一個具體的消息的過濾的時候，在Forum中有addForumMessageFilter()，applyFilters()方法，用來實現(xiàn)對過濾器的應用。
對一個Forum，使用addForumMessageFilter()方法添加一個Filter的時候，并沒有指定一個具體的Message，而只是一個規(guī)則（Filter中封裝了過濾規(guī)則），然后applyFilter()方法中，實施這些規(guī)則：
public ForumMessage applyFilters(ForumMessage message) {
//Loop through filters and apply them
for (int i=0; i < filters.length; i++) {
message = filters[i].clone(message);
}
return message;
}
|
過濾器的clone()方法，為過濾器復制消息體。這個方法的使用，分離了在過濾器中對于消息體和過濾規(guī)則的初始化過程，這也是一個值得借鑒的技巧！
下面給出Decorator模式的類圖:
圖4：Decorator模式的類圖
我們可以看到Decorator模式實際上和Proxy模式是很相近的，但是它們代表兩個不同的功能含義。Proxy模式提供一個對象的控制，而Decorator模式則是為對象提供額外的功能。
Iterator模式和論壇的瀏覽erator模式用來分離數(shù)據(jù)結構和遍歷算法，降低兩者之間的耦合度，以使得同一個數(shù)據(jù)結構用不同的算法遍歷時，仍能夠具有相同的接口，另一方面，Iterator模式使得當改換遍歷算法后，不需要更改程序的代碼。
在Java的JDK中本身就定義有一個Iterator接口，在Iterator接口中僅僅定義了三個方法，hasNext()判斷是否遍歷完最后一個元素，next()方法返回要遍歷的數(shù)據(jù)結構中一個對象，remove()則刪除當前對象。Jive中使用IteratorProxy抽象類繼承了這一接口。這兒Proxy的含義和上面一樣，也就是說，這個IteratorProxy出了會實現(xiàn)Iterator的遍歷功能外，還會有代理權限控制的功能。
對于論壇中的基本對象Forum，F(xiàn)orumThread，F(xiàn)orumMessage，Group，User都有相應的遍歷器。比如對應于Forum接口有ForumIteratorProxy對象。這個ForumIteratorProxy遍歷器就相當于一個封裝了一系列Forum對象的集合類，通過定義好的接口hasNext()和next()可以方便的遍歷這個集合，而并不需要知道是如何遍歷這個集合的。遍歷的算法可能很簡單，也可能很復雜，但是對于外部的客戶而言，這并沒有任何的區(qū)別。
而對于論壇中具體的遍歷方法，這取決于具體的實現(xiàn)，在Jive中給出的是數(shù)據(jù)庫的實現(xiàn)。
我們就以MessageIteratorProxy為例，來講解Iterator模式的用法。
DbThreadIterator對象實現(xiàn)了Iterator接口，是對于一個Thread中所有Message的遍歷器，我們來看看它是如何實現(xiàn)的。
hasNext()判斷在這個Thread中是不是還有下一條Message：
public boolean hasNext() {
if (currentIndex+1 >= messages.length) {
return false;
}
return true;
}
|
next()方法從數(shù)據(jù)庫中取出與在這個Thread中的下一條Message：
public Object next() throws java.util.NoSuchElementException {
ForumMessage message = null;
if (nextMessage != null) {
message = nextMessage;
nextMessage = null;
}
else {
message = getNextMessage();
if (message == null) {
throw new java.util.NoSuchElementException();
}
}
return message;
}
|
這樣，通過對數(shù)據(jù)庫的操作，DbThreadIterator實現(xiàn)了對一個Thread中所有Message遍歷的方法。
再ForumThread接口中有messages()方法，返回在這個Thread中的所有Message的一個遍歷器（Iterator），實際上也就是返回了一個Message的集合：
public Iterator messages();
在DbForumThread中實現(xiàn)了這個方法：
public Iterator messages() {return new DbThreadIterator(this);}
從DbForumThread的messages()方法中所返回的就是這個Thread中所有Message的一個遍歷器，通過這個遍歷器，我們就可以訪問Thread中的所有的Message了。當然，事情還沒有完，由于權限的問題，我們還需要構造這個遍歷器的Proxy對象，然后通過這個Proxy對象來訪問遍歷器。
下面的類圖給出了在Jive中Iterator模式的實現(xiàn)方法：
圖5：Jive中Iterator模式的實現(xiàn)
在Jive中，因為在一個Thread之下，Message是按樹形結構組織的，因而，當需要層級表示一個Thread中的Message之間的關系的時候，僅僅用上面講到的線性的Iterator是不夠的。這時候，對Iterator的概念進行推廣，就引入了TreeWalker接口。
顧名思義，TreeWalker提供了遍歷一個樹和存取樹上節(jié)點的方法：
public interface TreeWalker {
public ForumMessage getRoot();
public ForumMessage getChild(ForumMessage parent, int index);
public int getChildCount(ForumMessage parent);
public int getRecursiveChildCount(ForumMessage parent);
public int getIndexOfChild(ForumMessage parent, ForumMessage child);
public boolean isLeaf(ForumMessage node);
|
TreeWalker只是Iterator的簡單推廣，并沒有Iterator應用的那么廣泛，而且，也可以很容易的在TreeWalker上面在套一層Iterator的借口，讓它在某些情況下行使Iterator的職責。這兒就不再多討論了。
再此，Jive設計中所有涉及到的設計模式的地方，基本上都講完了，看完了之后，是不是對設計模式有了更進一步的了解了呢？
下一部分的內容，將會涉及到具體的編碼，深入到JSP的內部，我們將會看到Jive中是如何實現(xiàn)可更換的Skin的，還會涉及Tag Library的一些內容。好了，這次就到這兒了。下次再見。