到今天為止把建立型的幾種設計模式算是學完了,搞一段落.進行一下總結.
時間比較短,還好建立型的比較簡單,以後估計不會這麼順利了.由於沒有真正的實踐在專案中,所以到現在為止,我認為我還沒有掌握,僅僅是對設計模式有些了解而已.
建立型模式,主要用來解決new所帶來的物件間的耦合關係,除了singleton和prototype之外,都需要使用factory來負責物件的例項化，prototype是通過原型（也就是抽象）來轉殖物件。
白話一點兒說，建立型模式就是把有可能經常變化的物件單獨拎出來處理，使這些經常變化的部分在發生變化時不會影響整個系統。
gof設計模式有5種是建立模式.
其中singleton模式用來控制物件建立的個數,一般是乙個,可以通過變化建立指定數量的物件.
factory method模式是最最基礎的建立型模式，也是最基礎的設計模式之一。既然是物件導向程式設計，當然要建立物件。factory method模式就是解決了物件的基本建立問題。物件通過自己的工廠建立例項，在建立點不依賴具體實現而僅僅依賴於物件自己的抽象。編譯時只知道要建立哪種物件（抽象），執行時才知道具體會建立這種物件的哪個物件。反正一種物件的行為都是相似的，所以抽象也是一樣的。只是具體實現不同。比如車都能轉彎，只是電單車和汽車轉彎的具體實現不同，但抽象是相同的。這裡編譯時只說車要轉彎，在執行時再具體告訴程式是哪個車要轉彎。
abstract factory模式是在factory method模式的基礎上發展而來， factory method模式只解決了建立哪個物件的問題，而abstract factory解決了建立哪個系列物件的問題。這一系列物件之間可能有很多關聯和互動。白話點而說就是，比如我們肯定都用床上用品，包括床單，被罩和枕巾等。我們不會一輩子都用一套吧，肯定要換洗的，有壞的還得換新的（這裡假設整套整套壞/換）。那麼abstract factory就用上了。一次建立一套床上用品，不用修改任何地方，只需要增加新的床單類，被罩類和枕巾類，然後在呼叫時告訴系統，我要用這個新的。就ok了，符合了物件導向的對修改關閉對擴充套件開放的原則。
builder模式與factory method一樣，都是建立乙個物件。但是它卻是建立了乙個超級複雜的物件。它可以讓我們通過相同的建立過程建立出不同的表示。在這裡，建立物件的演算法是穩定的，但是物件的各個部分卻是不穩定的，經常會變。比如要建造乙個房子，建造房子的過程，比如打地基，搭架子，壘磚這些骨幹的過程是不變的，這是穩定的演算法。但是在造門和窗戶的時候卻有可能經常發生變化。有可能這個房子要用a工廠的門，那個房子卻要用b工廠的門。這是就要用到builder模式了。不管你用誰的門，但是造出來的肯定得是房子。
prototype模式詮釋了物件導向的依賴倒置原則。當乙個manager物件依賴某個具體實現時，我們把這個實現抽象出來（前提是這個物件是易變的），使manager物件依賴於這個抽象，這樣，以後擴充套件新的基於這個抽象的實現就會easy了。而manager裡通過抽象的轉殖建立需要數量的物件。這樣，manager只依賴抽象。我想這也是我們提倡面向介面程式設計的原因。
總之，建立型模式解決了軟體設計中物件建立的問題，通常，往往是我們遇到了易變類，才會使用建立型模式，至於使用哪種，就要看易變類和系統的特性了。
建立型設計模式總結
注意單件模式在多執行緒的問題。abstract factory抽象工廠 例子 遊戲中不同系列的設施建立 古典的，現代的.但是對於系列中的物件 道路，房屋.這些是不變的，不 會需要增加乙個 下水道 物件 簡單工廠的問題 不能應對 不同系列物件 的變化，有了新的變化點。一系列相互依賴的物件 抽象工廠的缺...
設計模式 建立型總結
factory 問題 1.為了提高內聚 cohesion 和松耦合 coupling 經常會抽象出一些類的公共介面以形成抽象基類或介面 可以通過宣告乙個向基類的指標來指向實際的子類實現 達到多型目的 1 客戶程式設計師必須知道實際子類的名稱 2 程式的擴充套件性和維護變得越來越困難 2.在父類中並不...
建立型設計模式
建立型設計模式對類的建立例項化過程進行抽象，將物件的建立和物件的使用分離。簡單工廠模式 使用頻率4星 工廠方法模式 使用頻率5星 抽象工廠模式 使用頻率5星 建造者模式 使用頻率2星 原型模式 使用頻率3星 單例模式 使用頻率4星 toc 簡單工廠模式將物件建立和物件使用相分離，降低了系統耦合度。優...