在軟體開發過程中，有很多人抱怨著需求的變化，是需求沒有做好麼？不是的，其實需求變化在軟體開發中是不可避免的。做人也是一樣，出了問題要先從自己這邊找原因，然後想辦法解決。我們身為程式設計師，向使用者和需求分析師們抱怨（其實，任何一種抱怨都是沒有意義的），是沒有意義的。究竟怎樣解決這個問題呢？我身邊很多人都有這種苦惱，竟然沒人去想，難道我身邊的這群人都不懂設計模式？悲劇……
我始終堅信，在軟體開發裡：優秀的演算法+優秀的設計模式+優秀的架構=nothing impossible！（這句話是原創！）
以上是題外話，就此打住。這次的重點是工廠方法設計模式。
在軟體系統中，由於需求的變化，"這個物件的具體實現"經常面臨著劇烈的變化，但它卻有比較穩定的介面。如何應對這種變化呢？提供一種封裝機制來隔離出"這個易變物件"的變化，從而保持系統中"其它依賴的物件"不隨需求的變化而變化。定義乙個使用者建立物件的介面或者定義好的抽象類，讓子類決定例項哪乙個類。factory method使乙個類的例項化延遲到子類。
以c#為例，下面是工廠方法模式設計的工廠和產品類結構圖：
其中的方法、屬性可以根據需要自定義。編譯生成factorymethod.dll。
static上面的**演示了，如何動態建立產品。void main(string
args)
factory factory = (factory)assembly.load("
factorymethod
").createinstance("
factorymethod.
" +factorytype); ;
//如果例項化成功，就輸出產品資訊
if (factory != null
)
else
} }
配置檔案中配置的是
xml version="1.0" encoding="utf-8"下面演示執行效果?>
<
configuration
>
<
>
<
add
key="type"
value
="factoryone"
/>
>
configuration
>
這樣有以下好處：
1.擴充套件性好，當需要擴充套件時，在**中新建相應的工廠和產品類即可，前台**無需更改。
2.當前臺需要更換產品型別時，只需要更改配置檔案即可，不用做任何其他的工作。
3.可重用，不解釋。
4.封裝性強，只要給乙個名字，就能叫乙個人來給你做出你想要的東西，很方便。
設計模式之工廠方法
工廠方法是在簡單工廠的基礎上的進一步抽象，在簡單工廠中，所有的物件都是通過乙個工廠來建立，在工廠方法中，每個物件都有特定的工廠來建立。抽象介面 車 package com.yf.designpattern.factorymethod public inte ce car 具體實現類 寶馬和賓士 pa...
設計模式之工廠方法
言歸正傳，後來 我們開始了重頭戲 設計模式 工廠三姐妹，因為十三期的師弟沒有接觸過這些知識二來因為自己學藝不精，所以當時講得有些吃力，這就尷尬了 是吧 為了挽回一點顏面，當下決定回去寫一篇部落格，但是 經常說 但是 不好 不過因為因為一直奮戰在itoo 這個總結沒有及時地動手去做，不過現在有時間了 ...
設計模式之工廠方法
軟體架構師需要關係設計模式 當有提示時 客戶端最常用的是彈出message對話方塊 服務端最常用的是寫日誌檔案。下面的例子假定五個開發組參與 核心邏輯組 class ishow class iglobe void init iglobe globe,uint uid 服務端業務邏輯組 namespa...