Amo Wu's Blog

有過網頁設計經驗的人，無論是部落格樣版或是其他頁面，都一定有個共同的痛，就是IE6這傢伙對CSS的呈現總是跟別人不同，偏偏它的市占率一直是最高的。 通常解決這個問題的方法有兩種，一種是修改CSS直到版面看起來正常，另一種則是直接放棄，在網頁開頭就提醒使用者升級瀏覽器。 我們今天要介紹的就是最後一種方法，為什麼我們要放棄IE6呢? 因為網頁技術不斷的進步，不單單是CSS的問題，IE6本身還有其他原因，它已經不適合這個世代了，加上最近許多知名網站也紛紛開始提倡升級IE6，例如You Tube、Twitter和Facebook等，IE6你真的玩完了，拜託還在使用IE6的人，請你快點更換瀏覽器吧!! (小聲:換 Firefox Chrome吧) 知名影音分享網站YouTube將停止對IE6的支援。 連最近在台灣火熱的Facebook都要封殺IE6了，還在使用它的人，麻煩你快點更新吧!!!

距離上一篇 Strategy pattern 策略模式 已經兩個多月了，一直拖到現在才生出這篇文章...orz。 其實這篇 工廠模式 應該要當作第一篇 Design pattern 的文章會比較好，因為這個模式很容易懂，但是 工廠模式 中又細分出一些其他類似的模式，例如 抽象工廠模式 ，所以我把一些相關的資料都讀了一遍後，分三篇作介紹。 工廠模式 最主要的精神就是將 new Class 這個動作另外封裝成一個 Factory Class，這個Factory Class 專門負責實體化這些類別。 特地這樣做有什麼好處呢? 舉個例子，假如我們現在有兩個繼承 Product 的類別，它們擁有 共同的方法 Operation() 一般來講，我們如果要實體化 ProductA 或 ProductB 的話，會這樣寫: 1: namespace FactoryPattern 2: { 3: class Program 4: { 5: static void Main( string [] args) 6: { 7: Product product = new ProductA(); 8:   9: product.Operation(); 10: } 11: } 12: } 這樣做有什麼缺點呢? 如果我 product 型別要換成 ProductB 的話，就需要把第7行的 new ProductA() 改成 new ProductB()，若是繼承 Product 的類別一多，以後程式碼的維護上會很麻煩。 簡單工廠模式 Simple Factory Pattern (又稱 靜態工廠模式 Static Factory Pattern ): 按照上圖，將擁有共同介面 類別的實體化動作封裝在 Factory 內，程式就可以在執行時 動態 決定要實體化哪個類別了。 Factory class: 1: namespace SimpleFactoryPattern 2: