什么是設(shè)計(jì)模式
設(shè)計(jì)模式是一套被反復(fù)使用、多數(shù)人知曉的、經(jīng)過(guò)分類編目的、代碼設(shè)計(jì)經(jīng)驗(yàn)的總結(jié)。使用設(shè)計(jì)模式是為了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。

毫無(wú)疑問(wèn)，設(shè)計(jì)模式于己于他人于系統(tǒng)都是多贏的，設(shè)計(jì)模式使代碼編制真正工程化，設(shè)計(jì)模式是軟件工程的基石，如同大廈的一塊塊磚石一樣。

GoF的“設(shè)計(jì)模式”是第一次將設(shè)計(jì)模式提升到理論高度，并將之規(guī)范化，本書提出了23種基本設(shè)計(jì)模式，自此，在可復(fù)用面向?qū)ο筌浖陌l(fā)展過(guò)程中，新的大量的設(shè)計(jì)模式不斷出現(xiàn)。

設(shè)計(jì)模式和框架
現(xiàn)在，可復(fù)用面向?qū)ο筌浖到y(tǒng)現(xiàn)在一般劃分為三大類：應(yīng)用程序 工具箱和框架(Framework),我們平時(shí)開發(fā)的具體軟件都是應(yīng)用程序；Java的API屬于工具箱;而框架是構(gòu)成一類特定軟件可復(fù)用設(shè)計(jì)的一組相互協(xié)作的類。EJB（Enterprise JavaBeans）是Java應(yīng)用于企業(yè)計(jì)算的框架.

框架通常定義了應(yīng)用體系的整體結(jié)構(gòu) 類和對(duì)象的關(guān)系等等設(shè)計(jì)參數(shù)，以便于具體應(yīng)用實(shí)現(xiàn)者能集中精力于應(yīng)用本身的特定細(xì)節(jié)。框架主要記錄軟件應(yīng)用中共同的設(shè)計(jì)決策，框架強(qiáng)調(diào)設(shè)計(jì)復(fù)用，因此框架設(shè)計(jì)中必然要使用設(shè)計(jì)模式.

另外，設(shè)計(jì)模式有助于對(duì)框架結(jié)構(gòu)的理解，成熟的框架通常使用了多種設(shè)計(jì)模式,如果你熟悉這些設(shè)計(jì)模式，毫無(wú)疑問(wèn)，你將迅速掌握框架的結(jié)構(gòu)，我們一般開發(fā)者如果突然接觸EJB J2EE等框架，會(huì)覺(jué)得特別難學(xué)，難掌握，那么轉(zhuǎn)而先掌握設(shè)計(jì)模式，無(wú)疑是給了你剖析EJB或J2EE系統(tǒng)的一把利器。

EJB中的設(shè)計(jì)模式
下面我們從設(shè)計(jì)模式的角度看看EJB的框架是怎樣的？在這之前假設(shè)你已經(jīng)大概了解了設(shè)計(jì)模式。專門的設(shè)計(jì)模式闡述請(qǐng)見我的設(shè)計(jì)模式之系列.

EJB是采取多層結(jié)構(gòu)，原先我們數(shù)據(jù)庫(kù)開發(fā)基本是應(yīng)用程序(商業(yè)邏輯運(yùn)算)直接調(diào)用數(shù)據(jù)庫(kù)驅(qū)動(dòng)，在EJB中，為將商業(yè)邏輯計(jì)算和數(shù)據(jù)庫(kù)截然分開，使用多個(gè)結(jié)構(gòu)式模式:Adapter模式和Bridge模式等.這樣做的好處顯然有三個(gè)：

1.分離了商業(yè)邏輯層和數(shù)據(jù)訪問(wèn)層;
2.能同時(shí)支持多個(gè)數(shù)據(jù)庫(kù)；
3.但數(shù)據(jù)庫(kù)類型更換時(shí)，不會(huì)設(shè)計(jì)到商業(yè)邏輯代碼的大量修改.

EJB中將對(duì)數(shù)據(jù)庫(kù)進(jìn)行調(diào)用(如發(fā)出select等語(yǔ)句)稱為會(huì)話bean(Sessionbean),而將對(duì)應(yīng)數(shù)據(jù)庫(kù)一個(gè)個(gè)記錄的bean稱為實(shí)體bean(Entity bean);由這兩種類型的bean完成對(duì)數(shù)據(jù)庫(kù)的訪問(wèn).

會(huì)話bean一般和客戶端應(yīng)用是一一對(duì)應(yīng)，而和數(shù)據(jù)庫(kù)端聯(lián)系緊密的是實(shí)體bean,EJB在實(shí)體bean(或直接在會(huì)話bean)和數(shù)據(jù)庫(kù)之間使用了Adapter模式和Bridge模式，無(wú)意在實(shí)體bean和數(shù)據(jù)庫(kù)之間又多了一層，稱之為DAO(Data Access Object )，DAO實(shí)際就是設(shè)計(jì)模式的混合體.

我們以Java的寵物店中的Catalog為例,這是專門處理寵物店中的寵物類別,在對(duì)數(shù)據(jù)庫(kù)訪問(wèn)中，有兩個(gè)主要程序：CatalogEJB和CatalogDAO,我們從具體代碼中看看設(shè)計(jì)模式是怎么應(yīng)用的.

Bridge模式和Adapter模式
我們首先看看CatalogEJB代碼：

public class CatalogEJB implements SessionBean {
　　protected CatalogDAO dao;

　　//從DAO工廠中獲取一個(gè)DAO 這是調(diào)用工廠(factory)模式的一個(gè)實(shí)例
　　public void ejbCreate() {
　　　　try {
　　　　　　dao = CatalogDAOFactory.getDAO();
　　　　}
　　　　catch (CatalogDAOSysException se) {
　　　　　　Debug.println("Exception getting dao " + se);
　　　　　　throw new EJBException(se.getMessage());
　　　　}
　　}

　　....

　

}



我們發(fā)現(xiàn)在CatalogEJB中并沒(méi)有通常的會(huì)話bean那樣有對(duì)數(shù)據(jù)庫(kù)操作的"select .. from ."等之類SQL操作語(yǔ)句，這些都被封裝到DAO的具體實(shí)現(xiàn)中(Concrete class).

在Catalog這個(gè)示例中使用了設(shè)計(jì)模式的Bridge模式,判斷是否是某種模式，主要依據(jù)其參與者的種類和相互關(guān)系，我們先看看Bridge模式的定義和參與者：

Bridge模式是將抽象和行為劃分開來(lái),各自獨(dú)立,但能動(dòng)態(tài)的結(jié)合起來(lái)（好象搭建了一座橋）。在本例中，是將商業(yè)邏輯和數(shù)據(jù)庫(kù)訪問(wèn)這樣的行為劃分開來(lái)，數(shù)據(jù)庫(kù)訪問(wèn)專門放置在DAO中了。

Bridge模式需要兩個(gè)接口(抽象類和接口通稱為接口)，一個(gè)用來(lái)封裝抽象部分，本例中是封裝商業(yè)邏輯，是CatalogEJB;還有一個(gè)是封裝行為(Implementor)，本例中是CatalogDAO,看看CatalogDAO代碼：


public interface CatalogDAO {

　　public Category getCategory(String categoryID, Locale l)
　　throws CatalogDAOSysException;

　　public Page getCategories(int start, int count, Locale l)
　　throws CatalogDAOSysException;

　　public Product getProduct(String productID, Locale l)
　　throws CatalogDAOSysException;

　　public Page getProducts(String categoryID, int start, int count, Locale l)
　　throws CatalogDAOSysException;

　　public Item getItem(String itemID, Locale l)
　　throws CatalogDAOSysException;

　　public Page getItems(String productID, int start, int size, Locale l)
　　throws CatalogDAOSysException;

　　public Page searchItems(String query, int start, int size, Locale l)
　　throws CatalogDAOSysException;


}


Bridge模式中參與者還需要有行為接口的具體實(shí)現(xiàn)(ConcreteImplementor),在本例中是CatalogDAOImpl,雖然在目前寵物店中只有一個(gè)ConcreteImplementor,但是可擴(kuò)展為到Mysql XML等數(shù)據(jù)源訪問(wèn),比如你可以自己新增一個(gè)叫CatalogDAOImplMysql，也是作為CatalogDAO的子類。

看看CatalogDAO的一個(gè)子類CatalogDAOImpl的代碼：

public class CatalogDAOImpl implements CatalogDAO {
　　protected static DataSource getDataSource()
　　　　throws CatalogDAOSysException {
　　　　try {
　　　　　　InitialContext ic = new InitialContext();
　　　　　　return (DataSource) ic.lookup(JNDINames.CATALOG_DATASOURCE);
　　　　}
　　　　catch (NamingException ne) {
　　　　　　throw new CatalogDAOSysException("NamingException while looking "
　　　　　　　　+ "up DB context : "
　　　　　　　　+ ne.getMessage());
　　　　}
　　}

　　//具體Select語(yǔ)句在這里出現(xiàn)，這里主要是Oracle 數(shù)據(jù)庫(kù)的訪問(wèn)語(yǔ)句

　　public Category getCategory(String categoryID, Locale l)
　　throws CatalogDAOSysException {

　　　　Connection c = null;
　　　　PreparedStatement ps = null;
　　　　ResultSet rs = null;
　　　　Category ret = null;

　　　　try {
　　　　　　c = getDataSource().getConnection();

　　　　　　ps = c.prepareStatement("select a.catid, name, descn "
　　　　　　　　　　+ "from (category a join "
　　　　　　　　　　+ "category_details b on "
　　　　　　　　　　+ "a.catid=b.catid) "
　　　　　　　　　　+ "where locale = ? "
　　　　　　　　　　+ "and a.catid = ?",
　　　　　　ResultSet.TYPE_SCROLL_INSENSITIVE,
　　　　　　ResultSet.CONCUR_READ_ONLY);
　　　　　　ps.setString(1, l.toString());
　　　　　　ps.setString(2, categoryID);
　　　　　　rs = ps.executeQuery();
　　　　　　if (rs.first()) {
　　　　　　　　ret = new Category(rs.getString(1).trim(),
　　　　　　　　rs.getString(2),
　　　　　　　　rs.getString(3));
　　　　　　}
　　　　　　rs.close();
　　　　　　ps.close();

　　　　　　c.close();
　　　　　　return ret;
　　　　}
　　　　catch (SQLException se) {
　　　　　　throw new CatalogDAOSysException("SQLException: "
　　　　　　+ se.getMessage());
　　　　}


　　　　....

}


Bridge模式參與者總結(jié)如下：

商業(yè)邏輯抽象類 (CatalogEJB)

抽象的商業(yè)邏輯操作.
對(duì)DAOImplementor調(diào)用.
不關(guān)心是具體什么數(shù)據(jù)源被使用(無(wú)論是Oracle還是JDBC還是XML).
DAO(Data Access Object) (CatalogDAO)

對(duì)數(shù)據(jù)源的抽象操作行為.
提供了非常方便訪問(wèn)和維護(hù)管理數(shù)據(jù)的API結(jié)構(gòu).
DAOImplementor (CatalogDAOImpl 有可能有CatalogDAOImplSybase CatalogDAOImplMysql 等)

實(shí)現(xiàn)具體的DAO接口內(nèi)容.
使用Adapter模式，將特定的數(shù)據(jù)源驅(qū)動(dòng)接口適配到DAO接口中去
數(shù)據(jù)源 ( Oracle, or Sybase database via JDBC API)

提供訪問(wèn)具體數(shù)據(jù)庫(kù)的驅(qū)動(dòng)接口，如包括連接池等.


在使用數(shù)據(jù)源驅(qū)動(dòng)接口時(shí)，需要使用Adapter模式，Adapter模式將兩個(gè)不相關(guān)的類糾合在一起使用，Adapter模式實(shí)際是使用組合(composition)和繼承(inheritance)兩種方式再生類，在著名的"think in Java"的"類再生"專門提到這兩個(gè)方式.

很顯然，如果你對(duì)Bridge模式和Adapter模式熟悉，那么對(duì)寵物店中的Catalog理解就會(huì)非常快，同樣，在寵物店其他部分如訂單 用戶注冊(cè) 等都能迅速理解。

Factory模式和Singleton模式
該模式類似new，是用來(lái)創(chuàng)建對(duì)象的，使用Factory模式是為了實(shí)現(xiàn)面向?qū)ο蟮幕驹瓌t.封裝(Encapsulation)和分派(Delegation);將創(chuàng)建對(duì)象與使用對(duì)象進(jìn)行分工。因此在平時(shí)開發(fā)過(guò)程中，盡量使用Factory模式創(chuàng)建對(duì)象。

本例CatalogEJB中是使用Factory模式獲得一個(gè)DAO的具體實(shí)例對(duì)象，見上面CatalogEJB代碼中注釋。我們看看CatalogDAOFactory的代碼:

public class CatalogDAOFactory {
　　public static CatalogDAO getDAO() throws CatalogDAOSysException {

　　　　CatalogDAO catDao = null;
　　　　try {
　　　　　　InitialContext ic = new InitialContext();
　　　　　　String className = (String) ic.lookup(JNDINames.CATALOG_DAO_CLASS);
　　　　　　catDao = (CatalogDAO) Class.forName(className).newInstance();
　　　　} catch (NamingException ne) {
　　　　　　...

　　　　}
　　　　return catDao;
}



在CatalogDAOFactory可以依據(jù)系統(tǒng)的配置文件，動(dòng)態(tài)獲得DAO的方法，之所以采取動(dòng)態(tài)方式，當(dāng)然便于用戶自己增加自己的DAO方式，而不必修改代碼，只要直接修改配置文件就可以。

如果在這里只需要CatalogDAOFactory產(chǎn)生一個(gè)實(shí)例,可以采取Singleton模式,Singleton的目的是控制類實(shí)例對(duì)象的創(chuàng)建，并且允許整個(gè)程序只在一點(diǎn)對(duì)它進(jìn)行訪問(wèn)。Singleton本身類只能創(chuàng)建一個(gè),是單線程。


public class CatalogDAOFactory {
　　private static CatalogDAO catDao = null;

　　public static CatalogDAO getIntance(){
　　　　if (catDao==null)
　　　　　　try {
　　　　　　　　InitialContext ic = new InitialContext();
　　　　　　　　String className =
　　　　　　　　 　　(String) ic.lookup(JNDINames.CATALOG_DAO_CLASS);
　　　　　　　　catDao = (CatalogDAO) Class.forName(className).newInstance();
　　　　　　} catch (NamingException ne) {
　　　　　　　　...

　　　　　　}
　　　　 }
　　　　return catDao;

　　}
}



那么在CatalogEJB的調(diào)用從
dao = CatalogDAOFactory.getDAO();
要改為
dao = CatalogDAOFactory.getIntance();

Facade模式
在EJB應(yīng)用中，有兩個(gè)端點(diǎn)，這一端是用戶端，另外一端是EJB,通常在這兩個(gè)端點(diǎn)間會(huì)增加一層，用來(lái)松散兩個(gè)端點(diǎn)之間的耦合，比如在寵物店例子中,考慮到不同身份的用戶有不同的操作流程，比如顧客注冊(cè)進(jìn)入后，需要瀏覽目錄，下訂單，而商店管理者進(jìn)入后需要確認(rèn)或者否定訂單，或者檢查庫(kù)存。這些功能需要借助Session bean和Entity bean完成。

但是如果用戶端直接和這些bean互動(dòng),會(huì)有以下問(wèn)題:


1. 用戶端必須注意和這些beans的所有有聯(lián)系或互動(dòng)的事情，無(wú)法阻止用戶端可能不恰當(dāng)?shù)氖褂眠@些beans.
2.如果EJB的API改動(dòng)，那么用戶端的一些代碼也要修改。無(wú)疑擴(kuò)展性很差。
3.即使這些beans都在同一臺(tái)服務(wù)器上，用戶端還是用remote方式來(lái)調(diào)用它們，造成網(wǎng)絡(luò)無(wú)故擁擠。

那么我們使用Facade模式來(lái)解決這個(gè)問(wèn)題，F(xiàn)acade的定義是為子系統(tǒng)中的一組接口提供一個(gè)一致的界面,很顯然我們需要為這些bean提供一個(gè)統(tǒng)一的對(duì)外界面。如下圖：


在寵物店中，ShoppingClientFacadeLocalEJB是面對(duì)所有用戶端操作的統(tǒng)一界面，用戶端操作就不直接和那些EJB如CustomerEJB或ShoppingCartEJB有聯(lián)系,而是都通過(guò)ShoppingClientFacadeLocalEJB來(lái)聯(lián)系的。代碼如下：

public class ShoppingClientFacadeLocalEJB implements SessionBean {
　　...

　　//和CustomerEJB聯(lián)系
　　public CustomerLocal getCustomer() throws FinderException {
　　　　if (userId == null) {
　　　　　　...
　　　　}
　　　　try {
　　　　　　InitialContext ic = new InitialContext();
　　　　　　Object o = ic.lookup("java:comp/env/ejb/petstore/local/customer");
　　　　　　CustomerLocalHome home =(CustomerLocalHome)o;
　　　　　　customer = home.findByPrimaryKey(userId);
　　　　} catch (javax.naming.NamingException nx) {
　　　　　 ...
　　　　}

　　　　return customer;
　　}

　　.....

　　//和ShoppingCartEJB聯(lián)系
　　public ShoppingCartLocal getShoppingCart() {
　　　　if (cart == null) {
　　　　　　try {
　　　　　　　　InitialContext ic = new InitialContext();
　　　　　　　　Object o = ic.lookup("java:comp/env/ejb/cart/Cart");
　　　　　　　　ShoppingCartLocalHome home =(ShoppingCartLocalHome)o;
　　　　　　　　cart = home.create();
　　　　　　} catch (javax.ejb.CreateException cx) {
　　　　　　　...
　　　　　　}
　　　　}
　　　　return cart;
　　}

　　....

}



Facade模式參與者：

SessionFacade (ShoppingClientFacadeLocalEJB)

提供一組操作流程
將真正工作委托到EJB的bean.
EJB的bean (CustomerEJB, ShoppingCartEJB等等)

執(zhí)行基本的商業(yè)邏輯操作
沒(méi)有任何對(duì)SessionFacade的調(diào)用.

這樣不但可擴(kuò)展性大大增強(qiáng)，效率也提高了，用戶端只需要一次Remote對(duì)SessionFacade調(diào)用就可以了，而SessionFacade會(huì)自動(dòng)定位到與它同一臺(tái)服務(wù)器的那些鄰居bean(CustomerEJB, ShoppingCartEJB等等),無(wú)疑減少網(wǎng)絡(luò)擁擠，提高了速度.

總結(jié)
在EJB的具體使用中，使用合適的設(shè)計(jì)模式，不但使代碼可重用性 可拓展性增強(qiáng)，最重要的是能提高效率和速度，我們知道EJB框架由于考慮大型系統(tǒng)中事務(wù)安全等各方面問(wèn)題，效率性能有所欠缺，那么我們?cè)诰唧w問(wèn)題具體應(yīng)用時(shí)，使用設(shè)計(jì)模式可以彌補(bǔ)這個(gè)問(wèn)題。

例如Proxy模式可以為我們?cè)谠L問(wèn)巨大的需要花費(fèi)一定時(shí)間才能展開的對(duì)象時(shí)，提供一個(gè)代理，這樣不會(huì)因?yàn)槟莻€(gè)巨大對(duì)象而影響當(dāng)前運(yùn)行速度，EJB中的那些bean很顯然屬于巨大對(duì)象（因?yàn)樗鼈冇蟹磸?fù)的數(shù)據(jù)庫(kù)操作，這些很費(fèi)時(shí)間〕。

Flyweight模式是避免大量擁有相同內(nèi)容的小類的開銷(如耗費(fèi)內(nèi)存),使大家共享一個(gè)類(元類).當(dāng)你要從EJB中獲取一系列字符串,而這些字符串中肯定有許多是重復(fù)的,那么我們可以將這些重復(fù)的字符串儲(chǔ)存在Flyweight池(pool)中以達(dá)到共享。