下列型錄包含3大類共23個設計模式，並列出其目的。
生成模式(Creational Patterns)
將物件具現化的過程抽象化地加以萃取，使系統能獨立於物件的建立、組成及表現方式之外。
- 工廠方法模式(Factory Method)
定義可資生成物件的介面，但讓子類別去決定該具現出哪一種類別的物件。此模式讓類別將具現化程序交付給子類別去處置。 - 抽象工廠模式(Abstract Factory)
以同一個介面來建立一整族相關或相依的物件，不需點明各物件真正所屬的具象類別。 - 建造者模式(Builder)
從複雜物件的佈局中抽取出生成程序，以便用同一個生成程序製造各種不同的物件佈局。 - 原型模式(Prototype)
制訂可用原型個體生成的物件類型，爾後只須複製此原型即可生成新物件。 - 獨體模式(Singleton)
確保類別只會有一個物件實體存在，並提供單一存取窗口。
結構模式(Structural Patterns)
在探討如何以類別和物件組合成大型的結構。
- 轉接器模式(Adapter)
將類別的介面轉換成外界所預期的另一種介面，讓原先囿於介面不相容問題而無法協力合作的類別能夠兜在一起用。 - 橋接模式(Bridge)
將實作體系與抽象體系分離開來，讓兩者能各自更動各自演進。 - 組合模式(Composite)
將物件組織成樹狀結構、「部分─全體」層級關係，讓外界以一致性的方式對待個別物件和整體物件。 - 裝飾模式(Decorator)
將額外權責動態附加於物件身上，不必衍生子賴別即可彈性擴增功能。 - 外觀模式(Façade)
替子系統裡一堆介面定義一套統一的高階介面，讓子系統更易使用。 - 享元模式(Flyweight )
以共享機制有效地支援一大堆小規模的物件。 - 代理模式(Proxy)
替其他物件預留代理者空位，藉此控制存取其他物件。
行為模式(Behavioral Patterns)
探討物件之間的演算法及權責分配問題。
- 解譯器模式(Interpreter)
針對標的語言定義出文法，以及可解讀這種語句的解釋器。 - 範本方法模式(Template Method)
對於操作，只先定義好演算法的輪廓，某些步驟則留給子類別去填補，以便在不改變演算法整體構造的情形下讓子類別去精鍊某些步驟。 - 職責鏈模式(Chain of Responsibility)
讓多個物件都有機會處理某一訊息，以降低訊息發送者和接收者之間的耦合關係。它將接收者物件串連起來，讓訊息流經其中，直到被處理了為止。 - 命令模式(Command)
將訊息封裝成物件，以便能用各種不同訊息、暫存、記錄、復原等方式加以參數化處理。 - 迭代器模式(Iterator)
毋須知曉聚合物件的內部細節，即可依序存取內含的每一個元素。 - 仲介者模式(Mediator)
定義可將一群物件互動方式封裝起來的物件。因為物件彼此不直接相互指涉，所以耦合性低，容易逐一變更互動關係。 - 備忘錄模式(Memento)
在不違反封裝性的前提下，捕捉物件的內部狀態並存在外面，以便日後回復至此一狀態。 - 觀察者模式(Observer)
定義一對多的物件依存關係，讓物件狀態一有變動，就自動通知其他相依物件作該做的更新動作。 - 狀態模式(State)
讓物件的外顯行為隨內部狀態改變而改變，彷彿連類別也變了似的。 - 策略模式(Strategy)
定義一整族演算法，將每一個演算法封裝起來，可互換使用，更可在不影響外界的情況下個別抽換所引用的演算法。 - 訪問者模式(Visitor)
定義能逐一施行於物件結構裡各個元素的操作，讓你不必修改作用對象的類別介面，就能定義新的操作。
對於上述設計模式的目的說明，看完與看懂是兩種不同的境界，若以投手與捕手做例子，看完23個設計模式就像捕手可以接到投手所投的球，但這不表示捕手知道投手為什麼會投這樣的球，看懂則是進入知其然的境界了。
###
###
沒有留言:
張貼留言