Java 設計模式

  1. Bridge  --- JDBC 驅動程式

      JDBC就是用於執行SQL語句的應用編程介面，JDBC驅動程式就是實現該介面的類；資料庫應用程式就是對資料庫操作的抽象，它依賴於JDBC驅動程式；只要提供JDBC驅動程式，資料庫應用程式就可以操作任何資料庫。JDBC的這種架構將抽象與具體實現相分離，使得資料庫應用程式和JDBC驅動程式能夠獨立地發展。

 

2. FactoryMethod

圖1是Factory Method 模式的結構圖,這裡提供了一些術語,讓我們可以進行更方便的描述:

1. Product: 需要建立的產品的抽象類別.
2. ConcreteProduct: Product的子類,一系列具體的產品.
3. Creator: 抽象建立器介面,聲明返回Product類型對象的Factory Method.
4. ConcreteCreator: 具體的建立器,重寫Creator中的Factory Method,返回ConcreteProduct類型的執行個體.

       

由此可以清楚的看出這樣的平行對應關係: Product <====> Creator ; ConreteProduct <====> ConreteCreator

抽象產品對應抽象建立器,具體產品對應具體建立器.這樣做的好處是什麼呢?為什麼我們不直接用具體的產品和具體的建立器完成需求呢?實際上我們也可以這樣做.但通過Factory Method模式來完成,客戶(client)只需引用抽象的Product和Creater,對具體的ConcreteProduct和ConcreteCreator可以毫不關心,這樣做我們可以獲得額外的好處:

• 首先用戶端可以統一從抽象建立器擷取產生的執行個體,Creator的作用將client和產品建立過程分離開來,客戶不用操心返回的是那一個具體的產品,也不用關心這些產品是如何建立的.同時,ConcreteProduct也被隱藏在Product後面,ConreteProduct繼承了Product的所有屬性,並實現了Product中定義的抽象方法,按照Java中的對象造型(cast)原則,通過ConcreteCreator產生的ConcreteProduct可以自動的上溯造型成Product.這樣一來,實質內容不同的ConcreteProduct就可以在形式上統一為Product,通過Creator提供給client來訪問.
• 其次,當我們添加一個新的ConcreteCreator時,由於Creator所提供的介面不變,用戶端程式不會有絲毫的改動,不會帶來動一發而牽全身的災難, 這就是良好封裝性的體現.但如果直接用ConcreteProduct和ConcreteCreator兩個類是無論如何也做不到這點的. 優良的物件導向設計鼓勵使用封裝(encapsulation)和委託(delegation),而Factory Method模式就是使用了封裝和委託的典型例子,這裡封裝是通過抽象建立器Creator來體現的,而委託則是通過抽象建立器把建立對象的責任完全交給具體建立器ConcreteCreator來體現的.