行爲型模式概述
- 行爲模式涉及到算法和對象間職責的分配。行爲模式不僅描述對象或類的模式，還描述它們之間的通信模式。這些模式刻劃了在運行時難以跟蹤的複雜的控制流。它們將你的注意 力從控制流轉移到對象間的聯繫方式上來
- 行爲類模式使用繼承機制在類間分派行爲。其中包括兩個這樣的模式：
- 其中TemplateMethod較爲簡單和常用。模板方法是一個算法的抽象定義，它逐步地定義該算法， 每一步調用一個抽象操作或一個原語操作，子類定義抽象操作以具體實現該算法
- 另一種行爲類模式是Interpreter。它將一個文法表示爲一個類層次，並實現一個解釋器作爲這些類的實例上的一個操作
- 行爲對象模式使用對象複合而不是繼承。一些行爲對象模式描述了一組對等的對象怎樣 相互協作以完成其中任一個對象都無法單獨完成的任務。這裏一個重要的問題是對等的對象 如何互相瞭解對方。對等對象可以保持顯式的對對方的引用，但那會增加它們的耦合度。在 極端情況下，每一個對象都要了解所有其他的對象。 Mediator在對等對象間引入一個mediator對象以避免這種情況的出現。mediator提供了鬆耦合所需的間接性
- Chain of Responsibility提供更鬆的耦合。它讓你通過一條候選對象鏈隱式的向一個對 象發送請求。根據運行時刻情況任一候選者都可以響應相應的請求。候選者的數目是任意的， 你可以在運行時刻決定哪些候選者參與到鏈中
- Observer模式定義並保持對象間的依賴關係。典型的Observer的例子是Smalltalk中的模型/視圖/控制器，其中一旦模型的狀態發生變化，模型的所有視圖都會得到通知
- 其他的行爲對象模式常將行爲封裝在一個對象中並將請求指派給它：
- Strategy模式將 算法封裝在對象中，這樣可以方便地指定和改變一個對象所使用的算法
- Command模式 將請求封裝在對象中，這樣它就可作爲參數來傳遞，也可以被存儲在歷史列表裏，或者以其 他方式使用
- State模式封裝一個對象的狀態，使得當這個對象的狀態對象變化時，該對象可改變它的行爲
- Visitor封裝分佈於多個類之間的行爲
- 而Iterator則抽象了訪問 和遍歷一個集合中的對象的方式
- 行爲型模式有：
- Chain of Responsibility（職責鏈）——對象行爲型模式：https://blog.csdn.net/qq_41453285/article/details/106201661
- Command（命令）——對象行爲型模式：https://blog.csdn.net/qq_41453285/article/details/106242934
- Interpreter（解釋器）——類行爲型模式：https://blog.csdn.net/qq_41453285/article/details/106242960
- Iterator（迭代器）——對象行爲型模式：https://blog.csdn.net/qq_41453285/article/details/106242970
- Mediator（中介者）——對象行爲型模式：https://blog.csdn.net/qq_41453285/article/details/106242982
- Memento（備忘錄）——對象行爲型模式：https://blog.csdn.net/qq_41453285/article/details/106242996
- Observer（觀察者）——對象行爲型模式：https://blog.csdn.net/qq_41453285/article/details/106201675
- State（狀態）——對象行爲型模式：https://blog.csdn.net/qq_41453285/article/details/106243009
- Strategy（策略）——對象行爲型模式：本文介紹
- Template Method（模板方法）——類行爲型模式：https://blog.csdn.net/qq_41453285/article/details/106243031
- Visitor（訪問者）——對象行爲型模式：https://blog.csdn.net/qq_41453285/article/details/106243048
一、意圖
- 定義一系列的算法，把它們一個個封裝起來，並且使它們可相互替換。本模式使得算法可獨 立於使用它的客戶而變化
二、別名
- 政策（Policy）
三、動機
- 有許多算法可對一個正文流進行分行。將這些算法硬編進使用它們的類中是不可取的， 其原因如下:
- 需要換行功能的客戶程序如果直接包含換行算法代碼的話將會變得複雜，這使得客戶程 序龐大並且難以維護，尤其當其需要支持多種換行算法時問題會更加嚴重
- 不同的時候需要不同的算法，我們不想支持我們並不使用的換行算法
- 當換行功能是客戶程序的一個難以分割的成分時，增加新的換行算法或改變現有算法將 十分困難。
- 我們可以定義一些類來封裝不同的換行算法，從而避免這些問題。一個以這種方法封裝 的算法稱爲一個策略（Strategy），如下圖所示
四、適用性
- 當存在以下情況時使用Strategy模式：
- 許多相關的類僅僅是行爲有異。“策略”提供了一種用多個行爲中的一個行爲來配置一 個類的方法
- 需要使用一個算法的不同變體。例如，你可能會定義一些反映不同的空間 /時間權衡的 算法。當這些變體實現爲一個算法的類層次時，可以使用策略模式
- 算法使用客戶不應該知道的數據。可使用策略模式以避免暴露覆雜的、與算法相關的數 據結構
- 一個類定義了多種行爲 , 並且這些行爲在這個類的操作中以多個條件語句的形式出現。 將相關的條件分支移入它們各自的Strategy類中以代替這些條件語句。
五、結構
六、參與者
- Strategy（策略） ：定義所有支持的算法的公共接口。 Context使用這個接口來調用某ConcreteStrategy定 義的算法
- ConcreteStrategy（具體策略）：以Strategy接口實現某具體算法
- Context（上下文） ：
- 用一個C o n c r e t e S t r a t e g y對象來配置
- 維護一個對Strategy對象的引用
- 可定義一個接口來讓Strategy訪問它的數據。
七、協作
- Strategy和Context相互作用以實現選定的算法。當算法被調用時，Context可以將該算法 所需要的所有數據都傳遞給該 S t a t e g y。或者，Context可以將自身作爲一個參數傳遞給Strategy操作。這就讓Strategy在需要時可以回調Context
- Context將它的客戶的請求轉發給它的Strategy。客戶通常創建並傳遞一個ConcreteStrategy對象給該Context；這樣, 客戶僅與Context交互。通常有一系列的ConcreteStrategy類可供 客戶從中選擇
八、效果
- 待續（學習到的時候再回來補）
九、實現
- 待續（學習到的時候再回來補）
十、代碼示例
- 待續（學習到的時候再回來補）
十一、相關模式
- Flyweight：Strategy對象經常是很好的輕量級對象