這個設計模式系列的第一篇
只是把創造對象的代碼簡單的移到一個專門用來創建對象的類中，叫簡單工廠，它更像一種好的編程習慣而不是一種模式。
而靜態工廠函數則是類自己提供了一個靜態的方法用來產生自己的對象（或者子類對象），它的好處有很多，經典的可以用來創建單例模式，或者創建實例受限制的多例模式。
工廠方法模式就是一種比較好用的模式了，它將創建對象的工作延遲到子類，代碼依賴於抽象而不是具體，這種模式我感覺又有點像模板方法模式。
抽象工廠模式則是基於工廠方法模式，它針對一個產品族了。
簡單工廠保證代碼的可複用,各個子類完全分離,避免了更高代碼無意中把原來好的源代碼改錯,對於開發公司來說,個人自用負責自己對應的子類,就行了,公司也不用把別的子類給你,
比如，如果現在公司要求你爲公司的薪資管理系統做維護，原來只有技術人員（月薪） ，市場銷售人員（底薪+提成），經理（年薪+股份）三種運算算法，現在要增加兼職工作人員的（時薪）算法，但按照前面的程序寫法，公司就必須要把包含有的原三種算法的運算類給你，讓你修改，你如果心中小算盤一打，‘TMD，公司給我的工資這麼低，我真是鬱悶，這會有機會了’，於是你除了增加了兼職算法以外，在技術人員（月薪）算法中寫了一句
if (員工是自己)
{
salary = salary * 1.1;
}
那就意味着，你的月薪每月都會增加10%（小心被抓去坐牢），本來是讓你加一個功能，卻使得原有的運行良好的功能代碼產生了變化，這個風險太大了。我們應該把加減乘除等運算分離，修改其中一個不影響另外的幾個，增加運算算法也不影響其它代碼”
這時候就需要用到 簡單工廠模式了
讓我們來看看這個例子，“我要發表博客”。
現在我要發表博客，這是我的一個想法，我想發表2篇，一篇是python的，一篇是java的。但他們都是博客，所以都有發表時間和題目倆個屬性。但是在我寫好具體的博客之前，博客這個概念還存在於我的腦海之中，實體還沒有出來。
在這裏，博客這個概念就是接口，我的腦子就是工廠，可以生產不同的符合有不同時間不同標題的博客實體出來，這些博客實體，則是實現了博客這個概念的具體實現。
package com.garfield.simplefactory;
/**
* 這是一個接口，就是我腦子裏對博客的一個抽象概念
* 他們都有時間和標題倆個共同的特點
* @author Garfield
*
*/
interface Blog{
public void getTime();
public void getTitle();
}
/**
* 這個是具體的實現類，就是我腦海裏博客的具體文章
* 關於Python的
* @author Garfield
*
*/
class Python implements Blog{
public void getTime(){
System.out.println("博客>>Python<<發表的時間是：XXXXXX");
}
public void getTitle(){
System.out.println("博客>>Python<<的標題是：XXXXXXX");
}
}
/**
* 這個是具體的實現類，就是我腦海裏博客的具體文章
* 關於JAVA的
* @author Garfield
*
*/
class Java implements Blog{
public void getTime(){
System.out.println("博客>>Java<<發表的時間是：XXXXXX");
}
public void getTitle(){
System.out.println("博客>>Java<<的標題是：XXXXXXX");
}
}
/**
* 這個是核心工廠類，他負責根據需求生成具體的產品
* 客戶端需要哪個博客，只要把名字傳給工廠就好了
* 客戶端不關心博客具體是怎麼生成的，只要傳回客戶端需要的東西就好了
* @author Garfield
*
*/
class Factory{
public static Blog getBlogInstance(String name){
Blog blog=null;
try {
//利用反射得到汽車類型
blog=(Blog)Class.forName("com.garfield.simplefactory."+name).newInstance();
} catch (InstantiationException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (IllegalAccessException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (ClassNotFoundException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
return blog;
}
}
/**
* 客戶端測試類
* 從客戶端的角度看，客戶看到的東西有
* 1.Blog一個藉口，是我的概念，裏邊是一些抽象的共同的方法和屬性
* 2.Factory工廠類以及我告訴客戶的，現有有Pyhon和JAVA倆種博客，你要哪個就寫哪個好了
* @author Garfield
*
*/
public class SimpleFactory {
public static void main(String[] args) {
Blog p=Factory.getBlogInstance("Python");
Blog j=Factory.getBlogInstance("Java");
p.getTitle();
p.getTime();
j.getTitle();
j.getTime();
}
}輸出結果是：
如果我要新加一個博客，那麼只需要再加一個類，比如“C#”，繼承博客這個藉口。
其實，工廠模式細分可以分爲3中：簡單工廠模式，工廠方法模式和抽象工廠模式。 在簡單工廠模式中有一個工廠類，還有一個所有產品的超類（博客接口）和各個具體產品類。爲了讓客戶在系統運行期間動態的決定需要那種產品，所以提供了所有產品的超類（博客接口），這是利用的面向對象的多態機制。 通過提供了一個產品的超類類，在我們的系統需要別的形狀的時候只要加入一個實現這個超類的具體產品類（python，java，c#）就可以了。產品中確實自動添加了我們需要的新產品，但工廠沒有可以提供新產品的邏輯，必須修改源代碼，在if語言中加上創建新產品的邏輯，重新編譯系統纔可以。這一點違反了“開閉原則”，如何纔可以不違反原則呢，工廠方法模式的其他兩個模式作出瞭解決的方法，但不完全。但簡單工廠模式也是有優點的，要不然也沒有存在的理由了，優點就在於實現起來很簡單，對於一些本身就很簡單的系統沒有必要使用複雜的模式。
