基于Spring使用工廠模式實現(xiàn)程序解耦的示例

這篇文章主要介紹基于Spring使用工廠模式實現(xiàn)程序解耦的示例，文中介紹的非常詳細(xì)，具有一定的參考價值，感興趣的小伙伴們一定要看完！

1、 啥是耦合、解耦？

既然是程序解耦，那我們必須要先知道啥是耦合，耦合簡單來說就是程序的依賴關(guān)系，而依賴關(guān)系則主要包括

1、 類之間的依賴

2、 方法間的依賴

比如下面這段代碼：

 public class A{
    public int i;
  }

  public class B{
    public void put(A a){
      System.out.println(a.i);
    }
  }

上面這個例子中A類和B類之間存在一種強耦合關(guān)系，B類直接依賴A類，B類的put方法非A類類型不可，我們把這種情況叫做強耦合關(guān)系。

實際開發(fā)中應(yīng)該做到：編譯期不依賴，運行時才依賴。怎么理解呢？我們很容易想到多態(tài)向上轉(zhuǎn)型，是的，編譯時不確定，運行時才確定,當(dāng)然接觸面更廣一點的童鞋會想到接口回調(diào)，是的接口回調(diào)方式也能有效的解耦！如下代碼：

//一個接口叫做Inter，里面定義了一個happy（）方法，有兩個類A、B實現(xiàn)了這個接口

interface Inter{
  void happy();
}

class A implements Inter{

  @Override
  public void happy() {
    System.out.println("happy...A");
  }
}

class B implements Inter{

  @Override
  public void happy() {
    System.out.println("happy...B");
  }
}

public class Test{
  public void happys(Inter inter){
    inter.happy();
  }
}

是的，如上代碼正是典型的接口回調(diào)，Test類中的happys方法參數(shù)變的相對靈活起來，代碼中Test類與A類、B類之間就存在一種弱耦合關(guān)系，Test類的happys方法的參數(shù)可以使A類類型也可以是B類類型，不像強耦合關(guān)系中非A類類型不可的情形。

從某一意義上來講使用類的向上轉(zhuǎn)型或接口回調(diào)的方式進(jìn)行解耦都是利用多態(tài)的思想！

當(dāng)然解耦的方式還有很多，從根本意義上講實現(xiàn)低耦合就是對兩類之間進(jìn)行解耦，解除類之間的直接關(guān)系，將直接關(guān)系轉(zhuǎn)換成間接關(guān)系，從而也有很多設(shè)計模式也對程序進(jìn)行解耦，比如：適配器模式、觀察者模式、工廠模式....總之，必須明確一點：耦合性強的程序獨立性很差！

2、 jdbc程序進(jìn)行解耦

先來看一段代碼：

//1、注冊驅(qū)動
DriverManager.registerDriver(new com.mysql.jdbc.Driver()); //如果把jdbc的MySQLjar包依賴去除直接編譯失敗提示沒有mysql  
//2、獲取連接
Connection conn=DriverManager.getConnection("jdbc:mysql://localhost:3306/ufida","root","root");
//3、獲取操作數(shù)據(jù)庫的預(yù)處理對象
PreparedStatement pstm=conn.prepareStatement("select * from client");
//4、執(zhí)行SQL，得到結(jié)果集
ResultSet rs=pstm.executeQuery();
//5\遍歷結(jié)果集
while(rs.next()){
  System.out.println(rs.getString("name"));
}
//6、釋放資源
rs.close();
pstm.close();
conn.close();

等等等等，好熟悉好懷念的代碼.....

沒錯就是jdbc的代碼，不是用來懷舊的，而是如果這樣設(shè)計，你會覺得這樣的程序耦合性如何？又如何進(jìn)行解耦？先仔細(xì)思考一番。

一分鐘過去了.....

兩分鐘過去了.....

好了，我們都知道jdbc連接MySQL需要一個mysql-connector的jar包，如果我們把這個jar包依賴或者這個jar包給去掉，顯然上面的這個程序會編譯報錯，如下圖

顯然這樣的程序耦合性過高！于是我們可以這樣設(shè)計，將第一步的注冊驅(qū)動代碼new的方式改成反射的方式如下：

 //1、new的方式注冊驅(qū)動
DriverManager.registerDriver(new com.mysql.jdbc.Driver()); //如果把jdbc的MySQLjar包依賴去除直接編譯失敗提示沒有mysql相關(guān)的jar包

改為如下方式

 //2、反射的方式注冊驅(qū)動
Class.forName("com.mysql.jdbc.Driver"); //改用這種方式注冊驅(qū)動會發(fā)現(xiàn)不會編譯失敗，相比上面的方式相對解耦，但是依然存在缺陷：若連接改為Oracle數(shù)據(jù)庫，這里的字符串又要進(jìn)行改動！

正如注釋的解釋一樣，又一個缺陷就浮現(xiàn)了：若連接改為Oracle數(shù)據(jù)庫，這里的字符串又要進(jìn)行改動！

于是對于這個jdbc程序來說就有這樣的一個解耦思路：

第一步：通過反射來創(chuàng)建對象，盡量避免使用new關(guān)鍵字

第二步：通過讀取配置文件來獲取創(chuàng)建的對象全限定類名

3、傳統(tǒng)dao、service、controller的程序耦合性

順著jdbc程序的解耦思路，我們再來看看傳統(tǒng)dao、service、controller的程序耦合性分析

由于只是一個demo，省去dao層的操作.....

定義一個Service接口

public interface IAccountOldService{
  public void save();
}

Service接口實現(xiàn)類

public class AccountServiceOldImpl implements IAccountOldService{
  @Override
  public void save() {
    System.out.println("save成功一個賬戶....");
  }
}

controller代碼：

public class AccountCencollertOld {
  public static void main(String[] args) {
    IAccountOldService iaccount=new AccountServiceOldImpl (); 
    iaccount.save(); //運行結(jié)果：save成功一個賬戶....
  }
}

到這里，有何想法？表面上來看是沒有一點問題的，So Beautiful，但仔細(xì)的看。表現(xiàn)層與業(yè)務(wù)層、業(yè)務(wù)層與持久層緊緊的互相依賴關(guān)聯(lián)，這與我們開發(fā)程序的高內(nèi)聚低耦合原則相違背,哦My God,So Bad！我們順著jdbc程序的解耦思路，我們應(yīng)該盡量避免使用new關(guān)鍵字，我們發(fā)現(xiàn)這些層里面service層new 持久層dao，controller表現(xiàn)層new 業(yè)務(wù)層service....太糟糕了

那么對此，你有何解耦思路？

4、使用工廠模式實現(xiàn)解耦

別想了，工廠模式實現(xiàn)程序解耦你值得擁有！順著jdbc程序的解耦思路：

1、通過讀取配置文件來獲取創(chuàng)建的對象全限定類名
2、通過反射來創(chuàng)建對象，盡量避免使用new關(guān)鍵字

首先在resources目錄下中寫一個bean.properties配置類，具體內(nèi)容如下

accountServiceOld=com.factory.service.impl.AccountServiceOldImpl

接著使用工廠方法代碼：

/**
 * 一個創(chuàng)建Bean對象的工廠
 *
 *  1、需要一個配置文件來配置我們的service和dao  配置文件的內(nèi)容：唯一標(biāo)識=全限定類名（key-value）
 *  2、通過讀取配置文件中配置的內(nèi)容，反射創(chuàng)建對象
 *
 *  場景：主要是service調(diào)用dao，controller調(diào)用service的程序。這里面耦合性非常的高，互相new互相依賴
 *
 *  為了解耦，利用工廠模式進(jìn)行
 */
 public class BeanFactoryOld {
  private static Properties props;

  static{
    try {
      //實例化對象
      props = new Properties();

      //獲取properties文件的流對象
      InputStream in = BeanFactory.class.getClassLoader().getResourceAsStream("bean.properties");
      props.load(in);//加載其對應(yīng)路徑下的配置文件

    }catch (Exception e){
      throw new ExceptionInInitializerError("初始化properties失??！");
    }
  }

  //根據(jù)bean的名稱獲取bean對象
  public static Object getBean(String beanName){
    Object bean=null;
    try {
    String beanPath= props.getProperty(beanName);
    bean = Class.forName(beanPath).newInstance();  //這里的newInstance創(chuàng)建實例（默認(rèn)無參構(gòu)造器）每次執(zhí)行都需要創(chuàng)建一次
    } catch (Exception e) {
      e.printStackTrace();
    }
    return bean;
  }
}

此時，controller的代碼就可以編寫為

/**
 * 這里模擬一個controller調(diào)用service
 *
 */
public class AccountCencollertOld {
  public static void main(String[] args) {
  //  IAccountOldService iaccount=new AccountServiceOldImpl (); //使用工廠方法不再通過new方式

    IAccountOldService iaccount= (IAccountOldService) BeanFactoryOld.getBean("accountServiceOld");
    iaccount.save(); //運行結(jié)果：save成功一個賬戶....  說明成功調(diào)用了service
  }
}

通過運行結(jié)果，屬實沒毛病，成功降低程序耦合！So Beautiful！先高興一會吧，因為馬上出現(xiàn).....但是，隨之而來的問題又出現(xiàn)了，我們對這個controller進(jìn)行一下改寫

for(int i=0;i<5;i++){
    IAccountOldService iaccount= (IAccountOldService) BeanFactoryOld.getBean("accountServiceOld");
    iaccount.save(); 
   }

打印結(jié)果：

com.factory.service.impl.AccountServiceImpl@1540e19d
save成功一個賬戶....
com.factory.service.impl.AccountServiceImpl@677327b6
save成功一個賬戶....
com.factory.service.impl.AccountServiceImpl@14ae5a5
save成功一個賬戶....
com.factory.service.impl.AccountServiceImpl@7f31245a
save成功一個賬戶....
com.factory.service.impl.AccountServiceImpl@6d6f6e28
save成功一個賬戶....

打印的是五個不同的對象，說明是多例的，每次調(diào)用getBean的時候都會newInstance出一個新對象，如下

多例每次都要創(chuàng)建對象，資源浪費、效率低下

針對單例多例情況，我們再對service業(yè)務(wù)層代碼進(jìn)行修改：

public class AccountServiceImpl implements IAccountService {
  //定義類成員
  private int i=1; 

  @Override
  public void save() {
    System.out.println("save成功一個賬戶....");
    System.out.println(i);
    i++;
  }
}

運行controller代碼，運行結(jié)果

save成功一個賬戶....
1
save成功一個賬戶....
1
save成功一個賬戶....
1
save成功一個賬戶....
1
save成功一個賬戶....
1

why？多例因為每次都是新的對象，上面也驗證過了，因此每次創(chuàng)建新對象都會初始化一次，重新賦值，所以都是1，如果我們把類成員改為局部成員變量如下

public class AccountServiceOldImpl implements IAccountOldService {

//  private int i=1; 
  @Override
  public void save() {
    int i=1;  //改為局部變量
    System.out.println("save成功一個賬戶....");
    System.out.println(i);
    i++;
  }
}

不用猜，運行結(jié)果同樣是1。算了還是運行一下吧哈哈哈

save成功一個賬戶....
1
save成功一個賬戶....
1
save成功一個賬戶....
1
save成功一個賬戶....
1
save成功一個賬戶....
1

說了這么多，通過觀察service和dao之間單不單例好像無所謂，因為他們之間并沒有業(yè)務(wù)方法中改變的類成員，所以并不需要多例來保證線程安全。那說這些有何意義？不要忘了，由于使用了工廠改進(jìn)如下中的.newInstance創(chuàng)建實例（默認(rèn)無參構(gòu)造器）每次執(zhí)行都需要創(chuàng)建一次，這樣就不好了（浪費資源），因此我們要設(shè)計出只newInstance創(chuàng)建一次實例就很完美了，這也是我為啥要在service和controller中都添加一個Old關(guān)鍵字的原因了，接下來我們來看看工廠是如何改進(jìn)的！

5、工廠模式改進(jìn)

為了不被搞暈，我們重新寫代碼，也就是重頭開始寫代碼~其實就是把Old去掉~

由于只是一個demo，省去dao層的操作.....

定義一個Service接口

public interface IAccountService {
  public void save();
}

Service接口實現(xiàn)類

public class AccountServiceImpl implements IAccountService{

  @Override
  public void save() {
    System.out.println("save成功一個賬戶....");
  }
}

controller代碼：

/**
 * 這里模擬一個controller調(diào)用service
 *
 */
public class AccountCencollert {
  public static void main(String[] args) {
//    IAccountService iaccount=new AccountServiceImpl(); 

    IAccountService iaccount= (IAccountService) BeanFactory.getBean("accountService");
    iaccount.save(); //運行結(jié)果：save成功一個賬戶....  說明了成功調(diào)用了service
   }
 }

改進(jìn)的工廠方法代碼：

public class BeanFactory {
  private static Properties props;

  //定義一個map容器，用于存放創(chuàng)建的對象
  private static Map<String,Object> beans; //改進(jìn)的代碼============

  static{
    try {
      //實例化對象
      props = new Properties();

      //獲取properties文件的流對象
      InputStream in = BeanFactory.class.getClassLoader().getResourceAsStream("bean.properties");
      props.load(in);//加載其對應(yīng)路徑下的配置文件

      ////////////////////以下是改進(jìn)的代碼=======================
      //實例化容器
      beans=new HashMap<String,Object>();
      //取出配置文件中所有的key值
      Enumeration<Object> keys = props.keys();
      //遍歷枚舉
      while(keys.hasMoreElements()){
        //取出每個key
        String key = keys.nextElement().toString();
        //根據(jù)key取出對應(yīng)的value (這里因為每個value值對應(yīng)著類路徑)
        String beanPath = props.getProperty(key);
        //反射創(chuàng)建對象
        Object value = Class.forName(beanPath).newInstance();
        //把key和value存入容器中
        beans.put(key,value);
      }
    }catch (Exception e){
      throw new ExceptionInInitializerError("初始化properties失??！");
    }
  }


  //隨著代碼的改進(jìn)，我們就可以簡化下面的獲取bean對象的方法，如下代碼
  /**
   * 根據(jù)bean的名稱獲取對象（單例）
   */
  public static Object getBean(String beanName){
    //通過Map容器對應(yīng)key來獲取對應(yīng)對象
    return beans.get(beanName);  //這里通過Map容器中獲取，這樣就不會每次都創(chuàng)建一次實例！
  }

//不再使用下面的方法
 /*
  //根據(jù)bean的名稱獲取bean對象
  public static Object getBean(String beanName){
    Object bean=null;
    try {
    String beanPath= props.getProperty(beanName);
    bean = Class.forName(beanPath).newInstance();  //這里的newInstance創(chuàng)建實例（默認(rèn)無參構(gòu)造器）每次執(zhí)行都需要創(chuàng)建一次，這樣就不好了
    } catch (Exception e) {
      e.printStackTrace();
    }
    return bean;
  }*/
}

從上面改進(jìn)的工廠代碼，我們可以發(fā)現(xiàn)一開始就定義一個Map容器，用于存放創(chuàng)建的對象，為啥要先定義一個Map容器呢？用一個容器將這個實例裝起來，這是由于不把這個對象裝存起來的話，這個對象不使用很容易被GC掉，何況我們現(xiàn)在只使用這一個對象！

定義一個Map容器存放配置好的文件中的每個對象，之后我們就直接提供一個根據(jù)Map的key來取value的getBean方法，這樣不僅僅擴(kuò)展了程序的配置文件的靈活性而且還保證了只產(chǎn)生一個對象，保證資源不浪費，So Beautiful !

那如何證明已經(jīng)是單例的模式了呢？很簡單，如下設(shè)計一下service業(yè)務(wù)層、controller表現(xiàn)層代碼即可：

service業(yè)務(wù)層：添加一個類成員屬性，并在方法內(nèi)部 i++;

public class AccountServiceImpl implements IAccountService {

  private int i=1; //類成員屬性

  @Override
  public void save() {
    System.out.println("save成功一個賬戶....");
    System.out.println(i);
    i++;//二次改革代碼
  }
}

controller表現(xiàn)層: 創(chuàng)建調(diào)用工廠5次創(chuàng)建對象的方法

/**
 * 這里模擬一個controller調(diào)用service
 *
 */
public class AccountCencollert {
  public static void main(String[] args) {
    for(int i=0;i<5;i++){
      IAccountService iaccount= (IAccountService) BeanFactory.getBean("accountService");
      System.out.println(iaccount); //打印的是五個不同的對象，說明是多例的
      iaccount.save(); //會發(fā)現(xiàn)打印的i值都是1，并沒有自增成功
    }
  }

運行代碼結(jié)果：

com.factory.service.impl.AccountServiceImpl@1540e19d
save成功一個賬戶....
1
com.factory.service.impl.AccountServiceImpl@1540e19d
save成功一個賬戶....
2
com.factory.service.impl.AccountServiceImpl@1540e19d
save成功一個賬戶....
3
com.factory.service.impl.AccountServiceImpl@1540e19d
save成功一個賬戶....
4
com.factory.service.impl.AccountServiceImpl@1540e19d
save成功一個賬戶....
5

發(fā)現(xiàn)，確實5個對象都是同一個，并且出現(xiàn)了改變類成員屬性的現(xiàn)象。

如果我們把類成員屬性改為局部成員屬性呢？

public class AccountServiceImpl implements IAccountService {

  @Override
  public void save() {
    int i=1; //局部成員屬性
    System.out.println("save成功一個賬戶....");
    System.out.println(i);
    i++;
  }
}

運行結(jié)果

com.factory.service.impl.AccountServiceImpl@1540e19d
save成功一個賬戶....
1
com.factory.service.impl.AccountServiceImpl@1540e19d
save成功一個賬戶....
1
com.factory.service.impl.AccountServiceImpl@1540e19d
save成功一個賬戶....
1
com.factory.service.impl.AccountServiceImpl@1540e19d
save成功一個賬戶....
1
com.factory.service.impl.AccountServiceImpl@1540e19d
save成功一個賬戶....
1

看到這個結(jié)果，我們就能聯(lián)想到，之前為什么servlet中為啥要避免定義類成員，原因就在這里！多例情況下，就不會出現(xiàn)這種情況?。。?！

以上是“基于Spring使用工廠模式實現(xiàn)程序解耦的示例”這篇文章的所有內(nèi)容，感謝各位的閱讀！希望分享的內(nèi)容對大家有幫助，更多相關(guān)知識，歡迎關(guān)注億速云行業(yè)資訊頻道！