//細節:命名規則類，介面名稱都得大寫;
// 寫完程式碼記得格式化，就算是測試程式碼，貼出來也是給人看的。不能太水。
interface Fruit {
    //介面中的 public abstract 都是多餘的宣告，eclipse是發現不了的。
    //若是有心人就換編輯器，intellij idea，
    void eat();
}

class Apple implements Fruit {
    public void eat() {
        System.out.println("Apple");
    }
}

class Orange implements Fruit {
    public void eat() {
        System.out.println("Orange");
    }
}

class Factory {
    public static Fruit getInstance(String ClassName) {
        Fruit f = null;
        try {
            f = (Fruit) Class.forName(ClassName).newInstance();
        } catch (Exception e) {
            e.printStackTrace();
        }
        return f;
    }
}

class Hello {
    public static void main(String[] a) {
        Fruit f = Factory.getInstance("Reflect.Apple");
        if (f != null) {
            f.eat();
        }
    }
}
 

現在就算我們新增任意多個子類的時候，工廠類就不需要修改。

上面的程式碼雖然可以通過反射取得介面的例項，但是需要傳入完整的包和類名。而且使用者也無法知道一個介面有多少個可以使用的實現類

(程式碼是別人的，總結是自己的，就像jdk是別人的，理解是自己的一樣。)

不足之處:商品多的話，會出現海量的商品類，雖然在工廠中省去了具體判斷是什麼樣的商品，但是還是免不了去做一大堆的商品類。這個常不常用我就不敢妄加斷言啦。但是下面的三個規則還是存在的。只是工廠中省去了具體判斷。

總結下有以下三個方面，來實現一個工廠方法。

工廠規則：

有個介面，作用是提供一個規則，估計也可以是一個抽象類，提供大部分公共方法的實現也是可以的
工廠商品：

商品的種類很多，各不相同，但是都有一個共通點，那就是都遵守上面的工廠規則。具體實現可以實現介面或者繼承抽象方法等等。
工廠：

返回的是一個介面型別的商品物件，對外提供的也只是規則中包含的方法。根據商品之間的不同，來生產不同的商品。相當於父型別的引用指向其實現類或者子類，(多型)，當然，也可以型別強制轉換成子類物件。就像男人是人，人不一定是男人。類似這種關係。

Apple apple = (Apple) f;

咳咳，寫錯了，人能不強轉成男人，至於為啥就自己猜吧。

編譯時沒錯，執行時就炸了，這個也是多型的一個常問的問題。就不贅述啦