案例分析:設計模式與代碼的結構特性
工廠模式細分三種:簡單工廠模式、工廠模式、抽象工廠模式。
工廠模式相當于抽象了簡單工廠模式的工廠類,而抽象工廠模式在工廠模式的基礎上加上了產品族的概念。我選用的是抽象工廠模式來完成本次作業。
定義:是一種為訪問類提供一個創建一組相關或相互依賴對象的接口,且訪問類無須指定所要產品的具體類就能得到同族的不同等級的產品的模式結構。
使用條件:1)系統中有多個產品族,每個具體工廠創建同一族但屬于不同等級結構的產品。2)系統一次只可能消費其中某一族產品,即同族的產品一起使用
功能:抽象工廠模式的一個主要功能是它能夠隔離要生成的具體產品類, 由于這些類的實際類名部被隱藏在工廠內部,因此客戶端根本不需要關心如何對它們進行實例化的細節。每種設計模式都是針對特定問題的解決方案,而抽象工廠模式面臨的問題則是當涉及到有多個產品等級結構寸,如何更好地進行軟件體系結構的設計。
場景:對數據庫中的表進行修改
結構圖:

1) User表的定義:

2) 定義接口

3) 實現對mysql中User進行操作的類

實現對oracle中User進行操作的類

4) 定義一個工廠接口,用于生產訪問User表的對象

5) 生產mysqlUser對象的mysql工廠類

生產oracleUser對象的oracle工廠類

6) 用戶測試類

優點:
1)抽象工廠模式最大的好處是易于交換產品系列,由于具體工廠類,例如 IFactory factory=new OracleFactory(); 在一個應用中只需要在初始化的時候出現一次,這就使得改變一個應用的具體工廠變得非常容易,它只需要改變具體工廠即可使用不同的產品配置。不管是任何人的設計都無法去完全防止需求的更改,或者項目的維護,那么我們的理想便是讓改動變得最小、最容易,例如我現在要更改以上代碼的數據庫訪問時,只需要更改具體的工廠即可。2)抽象工廠模式的另一個好處就是它讓具體的創建實例過程與客戶端分離,客戶端是通過它們的抽象接口操作實例,產品實現類的具體類名也被具體的工廠實現類分離,不會出現在客戶端代碼中。就像我們上面的例子,客戶端只認識IUser和ILogin,至于它是MySQl里的表還是Oracle里的表就不知道了。
缺點:
1)如果你的需求來自增加功能,比如增加Login表,就有點太煩了。首先需要增加 ILogin,mysqlLogin,oracleLogin。 然后我們還要去修改工廠類: sqlFactory, mysqlFactory, oracleFactory 才可以實現,需要修改三個類,實在是有點麻煩。2)還有就是,客戶端程序肯定不止一個,每次都需要聲明sqlFactory factory=new MysqlFactory(), 如果有100個調用數據庫的類,就需要更改100次sqlFactory factory=new oracleFactory()。
浙公網安備 33010602011771號