JavaStudy——接口的應用：工廠設計模式

工廠設計模式是java開發中使用的最多的一種設計模式。本程式首先定義的一個表示水果的fruit接口。然後為Fruit定義的一個apple子類，在主類中通過Apple類執行個體化Fruit接口對象，是以當利用Fruit的接口對象調用eat( )方法時調用的是被子類覆寫過的方法。

public interface Fruit { // 定義接口

public void eat(); // 定義抽象方法

}

public class Apple implements Fruit{ // 定義接口子類

@Override

public void eat() { // 重寫接口方法

System.out.println("Andy like eat Apple!");

public class TestFruit {

public static void main(String[] args) {

Fruit f = new Apple(); // 子類執行個體化父類對象

f.eat();

本程式是讀者所熟知的程式結構。因為接口不能直接被執行個體化對象，是以必須利用向上轉型技術，通過子類執行個體化父類接口對象。但是這樣做并不是真的合理。

如果要确認一個代碼的編寫發編寫風格是否良好，應遵從于以下兩個标準。

用戶端(現為主方法）調用簡單，不需要關注具體細節；

程式代碼的修改不影響用戶端的使用。即使用者可以不去關心代碼是否變更

根據以上兩個标準就可以發現本程式設計上的問題，本程式在取得接口的執行個體化對象時，明确的指明了實用的子類fruit，Fruit f = new Apple（）。關鍵的問題就出現在關鍵字new上，因為一個接口不可能隻有一個子類，是以fruit也可能産生多個子類對象。而一旦要擴充子類，用戶端中使用也就可能還會與新的子類有關系。下面通過程式來建立一個Orange子類

定義新的子類

本程式的用戶端上想要得到這個新的子類對象，就需要修改代碼

本程式用戶端的代碼更改的一個子類orange，是以修改了用戶端的代碼，将Apple子類替換為了Orange子類。

這個時候如果有更多的子類呢？難道每次去修改執行個體化接口的子類嗎？在這個過程中，用戶端關心的事情隻有一件，如何去擷取到Fruit接口對象，至于說這個對象是被哪個子類所執行個體化的，用戶端根本就不需要知道，是以在整個代碼的關鍵自new是最大的問題。

那麼該如何去解決關鍵字new所帶來的耦合度問題呢？不妨回顧一下JVM的核心原理。在java中，JVM為了解決程式與作業系統的耦合問題，在程式與作業系統之間加了一個中間過渡層——JVM。由于JVM比對不同的作業系統，JVM的核心支援不變，程式就可以在任意的作業系統間進行移植，是以解決辦法就産生了。

想辦法讓用戶端看見接口，不讓其看到子類，這就需要一個中間的工具類來取得接口對象。這樣用戶端就不需要關心接口子類，隻需要獲得工廠類（factory）程式類就可以取得接口的對象.

同時這也是spring開發架構設計的核心理念: 實際上這種耦合問題在很多項目開發中都會存在很多開發者面對這種愈合問題。往往會采用大量的結構設計進行回避，可是這樣的代碼維護成本太高了，是以在java開發中有一個spring架構，其核心目的就是解決這種代碼耦合問題。

增加一個工廠類過度。

本程式在用戶端的操作上取消了關鍵字new的使用，而factory get instance（）方法隻根據指定子類的标記取得。執行個體化對象這樣用戶端不需要再關注具體子類，也不需要關注factory是怎樣處理的，隻需要關注如何取得了接口對象，并且操作這樣的設計的開發中，就被稱為工廠設計模式。