Design Pattern: Factory Pattern (下)
十二月 11, 2007 作者:mrmu
類別: Design Patterns
上回介紹到腳踏車行終於得到了工廠(Factory)來處理製造方面的部份，那麼究竟還有什麼樣的問題呢？
目前只有一個工廠，當產品種類愈來愈多時，簡易工廠的方式一樣是難以管理的；或許可以建立多個工廠來分類處理不同的產品，聽來是個不錯的主意。首先就讓工廠成為抽象/虛擬類別(abtract/virtual class)，定義出它通用的成員以供繼承。在此，腳踏車行的功能較少，我們可以將工廠的功能與之結合。
// 當出現更多種類的Factory，且各個Factory都想發展獨特的製造方式
// 建立一個BicycleStore的抽象類別
public abstract class BicycleStore
{
public Bicycle orderBicycle(String type)
{
Bicycle oneBicycle;
oneBicycle = createBicycle(type);
oneBicycle.test();
oneBicycle.pack();
return oneBicycle;
}
abstract createBicycle(String type); //Factory method
}
// 一家BicycleStore的instance (新的Factory)
public class GiantBicycleStore extends BicycleStore
{
Bicycle createBicycle(String item) //Factory method (unique!)
{
if (item.equals(“mountain“))
{
return new MountainBicycle();
}
else if (item.equals(“lady“))
{
return new LadyBicycle();
}
else
{
return null;
}
}
}
另外在腳踏車部份，我們也有了抽象類別以供繼承：
//Bicycle的抽象類別
public abstract class Bicycle
{
String ID;
String Handle;
String Tire;
void test();
void pack();
void getID();
void setID();
}
//一種Bicycle的instance
public class MountainBicycle extends Bicycle
{
ID = “MB123“;
Handle = “BendHandle“;
Tire = “Goodyeers“;
void test()
{
//unique test way for MB123;
}
}
如此的構造，便可稱之為Factory Pattern。
相關文章
DesignPattern: Factory Pattern (上)
十二月 10, 2007 作者:mrmu
類別: Design Patterns
最近有機會參與到Framework的設計與發展，於是開始trace一些open source的project，而SmartWin++即是首先觀察的對象。
一開始鑽進去看source code，發現它是template的重度使用者，很多高級用法尚未理解，索性先畫UML，看看它的長相。局部畫出它在元件(widget)方面的設計後，才發現，耶~「WidgetFactory」，這不是有名的Pattern嗎？又能有機會研究Design Pattern了。
昨天騎車上班時被撞，跑了兩家腳踏車行，所以就拿腳踏車來作為例子說明吧。(可惜服務態度都不好，騎腳踏車的人已經不多了，請好好珍惜顧客吧!)
開始製造腳踏車吧，一開始大概是這樣的:
Bicycle orderBicycle()
{
//製造
Bicycle oneBicycle = new Bicycle();
oneBicycle.test();
oneBicycle.pack();
return oneBicycle;
}
Order一台腳踏車，然後就被製造出來了。不過腳踏車可是有很多種類的，這種製造方法似乎還不夠。那麼這樣呢：
Bicycle orderBicycle(String type)
{
Bicycle oneBicycle;
if (type.equals(“mountain“))
{
oneBicycle = new MountainBicycle();
}
else if (type.equals(“lady“))
{
oneBicycle = new LadyBicycle();
}
else if (type.equals(“child“))
{
oneBicycle = new ChildBicycle();
}
oneBicycle.test();
oneBicycle.pack();
return oneBicycle;
}
哦! 看起來還不錯嘛!
不過這個世界是無常的，隨著時光飛逝，「少子化」的現象發燒，有天老闆決定小孩車不敷成本，不再生產了。反而著重在銀髮族群，於是可能會有這樣的改變：
Bicycle orderBicycle(String type)
{
Bicycle oneBicycle;
// 製造
if (type.equals(“mountain“))
{
oneBicycle = new MountainBicycle();
}
else if (type.equals(“lady“))
{
oneBicycle = new LadyBicycle();
}
// else if (type.equals(”child”)) // no more child bicycle!
// {
// oneBicycle = new ChildBicycle();
//}
else if (type.equals(“oldman“)) // new old man bicycle.
{
oneBicycle = new OldManBicycle();
}
oneBicycle.test();
oneBicycle.pack();
return oneBicycle;
}
呼~~費了一番工夫，調整了製造方式，什麼!? 又有新款車? 什麼!? XX車又不要了…
可以想像的到，日後只要新增車款或變更，你就要進來攪拌這盤 “義大利麵” 了… 好吧，我知道這些常常要改變的code，應該要分開來管理。有個比較聰明的作法，就是把它切出去 (也許請個誰來管理它吧)。
因為切出去的部份就是負責”製造”的部份，所以我們給它一個比較專業的名字－工廠 (Factory)。
來! 物件導向的設計呼之欲出:
//製造工廠
public class BicycleFactory
{
public Bicycle createBicycle (String type)
{
Bicycle oneBicycle = null;
if (type.equals(“mountain“))
{
oneBicycle = new MountainBicycle();
}
else if (type.equals(“lady“))
{
oneBicycle = new LadyBicycle();
}
// else if (type.equals(”child”)) // no more child bicycle!
// {
// oneBicycle = new ChildBicycle();
//}
else if (type.equals(“oldman“)) // new old man bicycle.
{
oneBicycle = new OldManBicycle();
}
return oneBicycle;
}
}
想像一下原來的orderBicycle()，應該是屬於腳踏車行提供的，所以我們也可以建立一個BicycleStore的Class：
public class BicycleStore
{
BicycleFactory oneFactory;
public BicycleStore (BicycleFactory factory)
{
this.oneFactory = factory;
}
public Bicycle orderBicycle(String type)
{
Bicycle oneBicycle;
oneBicycle = oneFactory.createBicycle(type);
oneBicycle.test();
oneBicycle.pack();
return oneBicycle;
}
}
故事發展至此，我們的”腳踏車行”得到了一個簡單的”工廠”，但這還不是真正的Factory Pattern呢，詳情下回分解。
