實用為主，學一些用得到的技術更能在如今的社會裡保命。 雖然在日常的工作中設計模式不是經常的用到，但是呢，學習它只有好處沒有壞處。
設計模式像是一種“標簽”，它是代碼編寫者思想的體現。有木有感覺到這樣很便捷？看到一些代碼的時候就很清楚的了解編寫者的思想了，這是為什麼呢？因為編寫者們用了“標簽”，而你恰恰是知道“標簽”意思的。 跟一異曲同工，在學習框架、了解框架的對象模型的時候，“標簽”是時常出現，如果你不了解“標簽”的意思那多痛苦啊！！！！！ 還有好多，不去一一闡述了。
工作中需求的變更時常令我們頭疼不已，總是要按著需求來重新的修改代碼，然後發布新的產品版本，或者是出更新包。 在需求變更中，對應著代碼也要修改，但是這修改也是分層次的。比如修改的模板在當初設計的時候遵循了開閉原則（OCP）的話，代碼的修改就變的輕松的多了。
我想制造出一個像電影《鋼鐵俠》裡面那樣的的一身盔甲，又或者說是機器吧，我把這個想法告訴了我的朋友們，他們都認為我瘋了。
好吧，我說的是用代碼抽象的制造出”鋼鐵俠“
廢話不多說，下面這個系列是用鋼鐵俠（IronMan)作為主題的設計模式 今天來學習簡單工廠模式、工廠方法模式、以及抽象工廠模式。
“玩具廠”：“噢！好的。Jin叫獸，時間方面還有什麼問題嘛？”
既然是這樣，那就從部件開始生產吧。
.strName =
RightHandComponent( .strName = strName = { { strName = }
.strName = strName = { { strName = }
開始生產
RightHandComponent rightcomponent = = LeftHandComponent();
若干的部件
被我一個個的按照圖紙給制造了出來。
這樣就可以拿rightcomponent、leftcomponent……等等的一些制造好的部件組裝了。
我也可以給“玩具廠”打電話了，可以交貨收錢。可是電話打完情況又變了，
中間的對話就不說了，“玩具廠”的意思就是這樣的。比如說“運輸途中”出現“損壞”，他們希望用一個很快捷便利的方式能得到部件。
嗯，我想了一下，不過對於我Jin叫獸來說都是小事，待我造出來一台部件生產器來。他們拿著機器自己回家生產不就ok了。
CreateComponent(
這樣生產的“機器”就好了，我得自己試用一下，看看效果怎麼樣。
RightHandComponent rightcomponent = IronManComponentFactory.CreateComponent() LeftHandComponent leftcomponent = IronManComponentFactory.CreateComponent() LeftHandComponent;
這樣反而多此一舉了，第一步，向機器輸入了命令以便自己獲得想要的部件，第二步，在生產出來後我還得把“圖紙”拿過來比對一下。 在我一籌莫展的時候，“玩具廠”給我發了個郵件，給我發了一份“部件規范說明書”，要求我的機器生產出的部件是達到說明書標准的。
那我們就來看一下這個所謂的“部件規范說明書”
strName =
{ { strName =
}
看完這個“部件規范說明書”，我已經無力吐槽，沒辦法了，只有重新設計部件了，“圖紙”要重新繪制，因為要按照那該死的“規范說明書”。
再看一下各個部件的“圖紙”
.Name =
RightHandComponent( .Name = Console.WriteLine( .Name = LeftHandComponent( .Name = Console.WriteLine( }
等等一些部件……
這下我再把原來的搭好的“生產機器”拆了，內部修改一下，來看一下修改後的“機器”
Component CreateComponent(
}
自己來測試一下：
Component rightcomponent = IronManComponentFactory.CreateComponent( Component leftcomponent = IronManComponentFactory.CreateComponent( leftcomponent.Self_Described();
於是，我很放心的就交給了“玩具廠”使用了，還得了個好評。
工廠方法
好景不長，“玩具廠”再次來電，提出一個要求，想讓我的“生產機器”裡面還可以生產更多的符合“部件規范說明書”的部件。
這樣說來是要改裝“生產機器”了。 可以說“玩具廠”是故意的，絕對是故意的。這下整蒙圈了，虧血本了，“生產機器”又要拆了…… 直接來看“生產機器”的圖紙
我們通過“取件口”取件
Component component = PottingFactrory.ComExit( component.Self_Described();
我們只要通過更換“生產插件”，從“取件口”獲得不同的部件。 或者更改需求，又要生產符合“規范說明書”的另一些產品的時候，可以自定義來實現“生產插件”，插入“生產機器”即可。
這樣可以送給“玩具廠”使用了。這次得到了很好的一個評價，我也可以休息一下了。
這裡的工廠方法是開閉原則（OCP)的實現，很優雅的顯示出了設計原則和設計模式的美。
這次“玩具廠”是把Iron部件升級了，二代部件出來了，是在一代的基礎上做了一些個性化的設計。來看新增部件的“圖紙” RightHandComponent2() : ( RightHandComponent2( .Name = Console.WriteLine( +
LeftHandComponent2() : ( LeftHandComponent2( .Name = Console.WriteLine( + }
按照“規范說明書”，添加了兩張“圖紙”，它們分別是二代的左右手部件。
部件的整體結構沒怎麼變，但是“生產機器”的“規范說明”就要更改了，以為在上面說到的“生產插件”也要重新更改。
先來看一下“生產機器”的“規范說明”：
factoryName = Console.WriteLine( + factoryName +
}
當然喽，“規范說明”都改了，那上面說過的兩個生產插件也得改了：
RightComFactory : IronManComponentFactory
.factoryName =
.factoryName =
LeftComFactory : IronManComponentFactory
.factoryName =
.factoryName = }
所要做的修改都是連帶關系，包裝”生產機器“的”取件口“也要改：
IronManComponentFactory comFactory =
{ { comFactory = .comFactory =
}
到這裡就差不多結束了。在工廠方法模式上 做了稍稍的（幾乎全改了）改動。
當然自己要先來測試一下喽：
PottingFactory pottingfact = PottingFactory( Component component= component = component.Self_Described();
我們來看一下結果：
End IronMan之旅才剛剛開始
