利用設計模式能夠使我們的**更靈活，更容易擴充套件，更容易維護。各種物件導向的程式語言都提供了基本相同的機制：比如類、繼承、派生、多型等等。但是又有各自的特色，c# 中的反射機制便是個很重要的工具，好好地利用就能夠在實際中發揮很大的作用。
我們來看乙個例子：
哦，我們都看設計模式，聽吧，很多人都在那裡鼓吹他們是如何如何的棒，我們看看怎麼樣利用他們來解決問題。目標明確了，那我們看看哪個能夠符合我們的需要。gof的《設計模式》都看過吧，似懂非懂的看了一些，那我們看看能夠不能夠「湊」上去呢？j 嗯，我們的程式考慮的是物件怎麼建立的，建立型模式應該符合需要吧。然後我們瀏覽一下各模式的「意圖」部分。呵呵，第乙個似乎就撞到彩了，抽象工廠，我們看看吧，「提供乙個建立一系列相關或相互依賴物件的介面，而無需指定他們具體的類」，至少「無需指定他們具體的類」符合我們的需要。來看看他的結構吧：
下面的一些東西顯然是我們需要的：
我們的fruitfactory應該是怎麼樣呢？上面的結構圖中他給的是createproducta,那好，我就makeorange，更有乙個createproductb,俺makeorange還不行？？
怎麼使用這個工廠呢？我們來寫下面的**：
編譯執行，然後在控制台輸入想要的東西，呵呵，成功了。沉浸在幸福中的您得意忘形了吧。
但是等等，他似乎還不完美，我假如想要pear，我既要在客戶**中的switch中加入判斷，又要在工廠方法中加入makepear方法，似乎不怎麼優雅。更好一點，在工廠中只提供乙個方法，makefruit，然後傳遞進乙個引數name，代表我們想要的水果的名稱，這樣的話，似乎我們的客戶**中的那個switch就能夠不要了，相反，在fruitfactory中似乎需要乙個，還等什麼呢？實現吧。
客戶**：
string fruitname = console.readline();
ifruit myfruit;
fruitfactory myfruitfactory = new fruitfactory();
myfruit = myfruitfactory.makefruit(fruitname);
這樣看起來好多了，至少我客戶**中不要再寫那麼一長串的判斷**了。
阿q精神又在起作用，我們又沉浸在成功的喜悅中了。 嗯，**似乎能夠，應該沒有什麼改進了。但是似乎又有另外乙個聲音在說：
「除了一點……」
「嗯？ 等等，什麼？」
「fruitfactory也有switch啊，看起來也ugly啊！」
「哼，肯定是看《重構》或是《tdd》了，怎麼需要那麼苛刻！反正閒著也是閒著，看看能夠改不？」
另外乙個重要的類就是system.activator，他包含特定的方法，用以在本地或從遠端建立物件型別，或獲取對現有遠端物件的引用。
我們能夠先利用type類獲取name指定的類名的類的type資訊，然後能夠根據這個資訊利用activator建立物件。還等什麼呢？
public class fruitfactory
catch (typeloadexception e)
console.writeline("i dont know this kind of fruit,exception caught - " ,e.message);
return myfruit;
} }
C 抽象工廠模式的幾種實現方法及比較
利用設計模式可以使我們的 更靈活，更容易擴充套件，更容易維護。各種 物件導向的程式語言都提供了基本相同的機制 比如類 繼承 派生 多型等等。但是又有各自的特色，c 中的反射機制便是乙個很重要的工具，好好地利用就可以在實際中發揮很大的作用。我們來看乙個例子 哦，我們都看設計模式，聽吧，很多人都在那裡鼓...
C 抽象工廠模式的幾種實現方法及比較
利用設計模式可以使我們的 更靈活，更容易擴充套件，更容易維護。各種物件導向的程式語言都提供了基本相同的機制 比如類 繼承 派生 多型等等。但是又有各自的特色，c 中的反射機制便是乙個很重要的工具，好好地利用就可以在實際中發揮很大的作用。我們來看乙個例子 哦，我們都看設計模式，聽吧，很多人都在那裡鼓吹...
C 抽象工廠模式的幾種實現方法及比較
利用設計模式可以使我們的 更靈活，更容易擴充套件，更容易維護。各種物件導向的程式語言都提供了基本相同的機制 比如類 繼承 派生 多型等等。但是又有各自的特色，c 中的反射機制便是乙個很重要的工具，好好地利用就可以在實際中發揮很大的作用 我們來看乙個例子 下面的一些東西顯然是我們需要的 public ...