怕是時間一久又搞混了簡單工廠模式、工廠方法模式和抽象工廠模式茵乱，還是輸出一下吧茂洒。這幾種模式說簡單，倒是真的不難瓶竭，就是自己怎么運用到平日項目中去督勺，這點讓我很是頭疼 。這篇文章我不會很細致地代碼UML圖相結合來介紹這幾種模式斤贰，如果是小白智哀，可以看這位四月葡萄
寫的Android的設計模式，可以說是很友好全面了荧恍，今天我主要就啰嗦兩句我覺得重要的點瓷叫，以便以后一看就記起。
（一）簡單工廠模式
優(yōu)點是代碼解耦送巡，創(chuàng)建實例的工作與使用實例的工作分開摹菠，使用者不必關心類對象如何創(chuàng)建。
簡單工廠模式有一個最大的問題——如果現在接口的子類增加了骗爆，那么工廠類肯定需要修改次氨，這樣違反了開閉原則（OCP）。因此可以使用反射來創(chuàng)建實例對象摘投。
packagecn.mldn.demo;
interface Fruit {
public void eat() ;
}
class Apple implements Fruit {
public void eat() {
System.out.println("吃蘋果煮寡。");
};
}
class Orange implements Fruit {
public void eat() {
System.out.println("吃橘子虹蓄。");
};
}
class Factory {
public static <T extends Fruit> T create(Class<T> clz) {
Fruit f = null;
try{
//看這兒看這兒~反射出實例
f = (Fruit) Class.forName(clz.getName()).newInstance() ;
} catch(Exception e) {
e.printStackTrace();
}
return (T)f ;
}
}
public class FactoryDemo {
public static void main(String[] args) {
//調用方式
Factory.create(Orange.class).eat();
Factory.create(Apple.class).eat();
}
}
利用反射后即使增加了接口的子類，工廠類照樣可以完成對象的實例化操作洲押，這個才是真正的工廠類武花，可以應對于所有的變化。但用反射的話杈帐，性能是一個問題体箕，反射相當于一系列解釋操作，通知jvm要做的事情挑童，性能比直接的java代碼要慢很多累铅。且不安全，通過反射機制我們能拿到類的私有成員站叼。
以前我對簡單工廠模式很有偏見娃兽，因為覺得它違反開閉原則的缺點實在是太明顯了。而在實際項目中我也會寫出缺點很明顯的代碼尽楔，很氣投储，但就是不知道怎么改進±觯或許我之前這么鄙視簡單工廠模式玛荞，其實是在鄙視寫臭臭代碼的自己呀。只能多學習多思考了呕寝。而且簡單工廠模式確實是有其優(yōu)點之處的呀勋眯，創(chuàng)建實例的工作與使用實例的工作分開~
參考：Java的反射機制
（二）工廠方法模式
沒什么值得說的，拷貝一個UML圖出來好了下梢。工廠方法模式每個工廠只能創(chuàng)建一種類型的產品客蹋。
（三）抽象工廠模式
其實大家看看這圖讶坯，很容易可以看出來如果增加新的產品,抽象工廠模式需要修改抽象工廠和所有的具體工廠,也違反了開閉原則。這就是抽象工廠模式的缺點了竟坛。
對比一下工廠方法模式和抽象工廠模式——
在工廠方法模式中具體工廠負責生產具體的產品闽巩，每一個具體工廠對應一種具體產品，工廠方法具有唯一性担汤。抽象工廠模式則可以能夠創(chuàng)建多種類型的產品涎跨，應用場景為生產多個產品組合的對象。抽象工廠模式代碼解耦崭歧，創(chuàng)建實例的工作與使用實例的工作分開隅很，使用者不必關心類對象如何創(chuàng)建。
溫故知新。工廠模式的初衷是解耦解耦解耦叔营，創(chuàng)建實例的工作與使用實例的工作分開屋彪，使用者不必關心類對象如何創(chuàng)建。
