模板方法與策略模式
策略模式是對算法的封裝，把一系列的算法分別封裝到對應的類中，並且這些類實現相同的接口，相互之間可以替換。在前面說過的行為類模式中，有一種模式也是關注對算法的封裝——模版方法模式，對照類圖可以看到，策略模式與模版方法模式的區別僅僅是多了一個單獨的封裝類Context，它與模版方法模式的區別在於：在模版方法模式中，調用算法的主體在抽象的父類中，而在策略模式中，調用算法的主體則是封裝到了封裝類Context中，抽象策略Strategy一般是一個接口，目的只是為了定義規范，里面一般不包含邏輯。其實，這只是通用實現，而在實際編程中，因為各個具體策略實現類之間難免存在一些相同的邏輯，為了避免重復的代碼，我們常常使用抽象類來擔任Strategy的角色，在里面封裝公共的代碼，因此，在很多應用的場景中，在策略模式中一般會看到模版方法模式的影子。
原文鏈接：https://blog.csdn.net/zhengzhb/java/article/details/7609670
策略模式的結構
封裝類：也叫上下文，對策略進行二次封裝，目的是避免高層模塊對策略的直接調用。
抽象策略：通常情況下為一個接口，當各個實現類中存在着重復的邏輯時，則使用抽象類來封裝這部分公共的代碼，此時，策略模式看上去更像是模版方法模式。
具體策略：具體策略角色通常由一組封裝了算法的類來擔任，這些類之間可以根據需要自由替換。
策略模式代碼實現
interface IStrategy {
public void doSomething();
}
class ConcreteStrategy1 implements IStrategy {
public void doSomething() {
System.out.println("具體策略1");
}
}
class ConcreteStrategy2 implements IStrategy {
public void doSomething() {
System.out.println("具體策略2");
}
}
class Context {
private IStrategy strategy;
public Context(IStrategy strategy){
this.strategy = strategy;
}
public void execute(){
strategy.doSomething();
}
}
public class Client {
public static void main(String[] args){
Context context;
System.out.println("-----執行策略1-----");
context = new Context(new ConcreteStrategy1());
context.execute();
System.out.println("-----執行策略2-----");
context = new Context(new ConcreteStrategy2());
context.execute();
}
}
策略模式的優缺點
策略模式的主要優點有：
l 策略類之間可以自由切換，由於策略類實現自同一個抽象，所以他們之間可以自由切換。
l 易於擴展，增加一個新的策略對策略模式來說非常容易，基本上可以在不改變原有代碼的基礎上進行擴展。
l 避免使用多重條件，如果不使用策略模式，對於所有的算法，必須使用條件語句進行連接，通過條件判斷來決定使用哪一種算法，在上一篇文章中我們已經提到，使用多重條件判斷是非常不容易維護的。
策略模式的缺點主要有兩個：
l 維護各個策略類會給開發帶來額外開銷，可能大家在這方面都有經驗：一般來說，策略類的數量超過5個，就比較令人頭疼了。
l 必須對客戶端（調用者）暴露所有的策略類，因為使用哪種策略是由客戶端來決定的，因此，客戶端應該知道有什么策略，並且了解各種策略之間的區別，否則，后果很嚴重。例如，有一個排序算法的策略模式，提供了快速排序、冒泡排序、選擇排序這三種算法，客戶端在使用這些算法之前，是不是先要明白這三種算法的適用情況？再比如，客戶端要使用一個容器，有鏈表實現的，也有數組實現的，客戶端是不是也要明白鏈表和數組有什么區別？就這一點來說是有悖於迪米特法則的。
適用場景
做面向對象設計的，對策略模式一定很熟悉，因為它實質上就是面向對象中的繼承和多態，在看完策略模式的通用代碼后，我想，即使之前從來沒有聽說過策略模式，在開發過程中也一定使用過它吧？至少在在以下兩種情況下，大家可以考慮使用策略模式，
幾個類的主要邏輯相同，只在部分邏輯的算法和行為上稍有區別的情況。
有幾種相似的行為，或者說算法，客戶端需要動態地決定使用哪一種，那么可以使用策略模式，將這些算法封裝起來供客戶端調用。
策略模式是一種簡單常用的模式，我們在進行開發的時候，會經常有意無意地使用它，一般來說，策略模式不會單獨使用，跟模版方法模式、工廠模式等混合使用的情況比較多。
模板方法模式 https://blog.csdn.net/hguisu/article/details/7564039
1.概述
在面向對象開發過程中，通常我們會遇到這樣的一個問題：我們知道一個算法所需的關鍵步驟，並確定了這些步驟的執行順序。但是某些步驟的具體實現是未知的，或者說某些步驟的實現與具體的環境相關。
例子1：銀行業務辦理流程
在銀行辦理業務時，一般都包含幾個基本固定步驟:
取號排隊->辦理具體業務->對銀行工作人員進行評分。
取號取號排隊和對銀行工作人員進行評分業務邏輯是一樣的。但是辦理具體業務是個不相同的，具體業務可能取款、存款或者轉賬。
2.問題
如何保證架構邏輯的正常執行，而不被子類破壞 ？
3.解決方案
模板方法：定義一個操作中的算法的骨架，而將一些步驟延遲到子類中。 T模板方法使得子類可以不改變一個算法的結構即可重定義該算法的某些特定步驟。（Template Method Pattern:Definethe skeleton of an algorithm in an operation,deferring some steps tosubclasses.Template Methodletssubclasses redefine certain steps of an algorithmwithoutchanging the algorithm's structure. ）
1）模板方法模式是基於繼承的代碼復用基本技術，模板方法模式的結構和用法也是面向對象設計的核心之一。在模板方法模式中，可以將相同的代碼放在父類中，而將不同的方法實現放在不同的子類中。
2）在模板方法模式中，我們需要准備一個抽象類，將部分邏輯以具體方法以及具體構造函數的形式實現，然后聲明一些抽象方法來讓子類實現剩余的邏輯。不同的子類可以以不同的方式實現這些抽象方法，從而對剩余的邏輯有不同的實現，這就是模板方法模式的用意。模板方法模式體現了面向對象的諸多重要思想，是一種使用頻率較高的模式。
4.適用性
模板方法應用於下列情況：
• 1） 一次性實現一個算法的不變的部分，並將可變的行為留給子類來實現。
• 2）各子類中公共的行為應被提取出來並集中到一個公共父類中以避免代碼重復。首先識別現有代碼中的不同之處，並且將不同之處分離為新的操作。最后，用一個調用這些新的操作的模板方法來替換這些不同的代碼。
• 3）控制子類擴展。模板方法只在特定點調用“ hook”操作 ，這樣就只允許在這些點進行擴展。
5.結構
6.模式的組成
抽象類（AbstractClass）: 定義抽象的原語操作（primitive operation） ，具體的子類將重定義它們以實現一個算法， 實現一個模板方法,定義一個算法的骨架。該模板方法不僅調用原語操作，也調用定義
具體子類 （ConcreteClass）: 實現原語操作以完成算法中與特定子類相關的步驟。
7.效果
模板方法模式的優點：
1)模板方法模式在一個類中形式化地定義算法，而由它的子類實現細節的處理。
2)模板方法是一種代碼復用的基本技術。它們在類庫中尤為重要，它們提取了類庫中的公共行為。
3)模板方法模式導致一種反向的控制結構，這種結構有時被稱為“好萊塢法則” ，即“別找我們，,我們找你”通過一個父類調用其子類的操作(而不是相反的子類調用父類)，通過對子類的擴展增加新的行為，符合“開閉原則”
模板方法模式的缺點:
每個不同的實現都需要定義一個子類，這會導致類的個數增加，系統更加龐大，設計也更加抽象，但是更加符合“單一職責原則”，使得類的內聚性得以提高。
8.實現
我們使用銀行業務實現，添加了hook方法，客戶自己覺得評價服務。
<?php
/**
* 模板方法模式：
*
* @author guisu
*/
/**
* 抽象類
*/
abstract class AbstractBank
{
private $_number ;
/**
*模板方法
* 因為子類不能覆寫一個被定義為final的方法。從而保證了子類的邏輯永遠由父類所控制。
*
*/
public final function templateMethodProcess()
{
$this->takeNumber();
$this->transact();
if($this->isEvaluateHook()) {
$this->evaluateHook();
}
}
/**
* 基本方法—具體方法
* 取號
*
*/
private function takeNumber()
{
return ++$this->_number;
}
/**
* //基本方法—抽象方法
*
*/
protected abstract function transact();
/**
* 基本方法—鈎子方法
*
*/
protected function evaluateHook() {
echo ' evaluateHook<br/>';
}
/**
* 基本方法—鈎子方法
*/
protected function isEvaluateHook() {
return true;
}
}
/**
* 具體子類:存款
*/
class ConcreteDeposit extends AbstractBank
{
public function transact() {
//實現代碼
echo 'Deposit', '<br>';
}
}
/**
* 具體子類:取款
*/
class ConcreteWithdraw extends AbstractBank
{
public function transact() {
//實現代碼
echo 'Withdraw', '<br>';
}
}
/**
* 具體子類:轉賬
*/
class ConcreteTrancfer extends AbstractBank
{
public function transact() {
//實現代碼
echo 'Trancfer', '<br>';
}
}
$c = new ConcreteTrancfer();
$c->templateMethodProcess();
9.與其他相關模式
1）策略模式：模板方法使用繼承來改變算法的一部分。 Strategy使用委托來改變整個算法。模板方法模式與策略模式的作用十分類似，有時可以用策略模式替代模板方法模式。模板方法模式通過繼承來實現代碼復用，而策略模式使用委托，把不確定的行為集中到一個接口中，並在主類委托這個接口。委托比繼承具有更大的靈活性。
10.模式的擴展
1）模板方法模式與控制反轉（好萊塢原則）在模板方法模式中，子類不顯式調用父類的方法，而是通過覆蓋父類的方法來實現某些具體的業務邏輯，父類控制對子類的調用，這種機制被稱為好萊塢原則(Hollywood Principle)，好萊塢原則的定義為：“不要給我們打電話，我們會給你打電話(Don‘t call us, we’ll call you)”。在好萊塢，把簡歷遞交給演藝公司后就只有回家等待。由演藝公司對整個娛樂項的完全控制，演員只能被動式的接受公司的差使,在需要的環節中，完成自己的演出。模板方法模式充分的體現了“好萊塢”原則。由父類完全控制着子類的邏輯，子類不需要調用父類，而通過父類來調用子類，子類可以實現父類的可變部份，卻繼承父類的邏輯,不能改變業務邏輯。
2）模板方法模式符合開閉原則
模板方法模式意圖是由抽象父類控制頂級邏輯，並把基本操作的實現推遲到子類去實現,這是通過繼承的手段來達到對象的復用，同時也遵守了開閉原則。
父類通過頂級邏輯，它通過定義並提供一個具體方法來實現，我們也稱之為模板方法。通常這個模板方法才是外部對象最關心的方法。在上面的銀行業務處理例子中，templateMethodProcess這個方法才是外部對象最關心的方法。所以它必須是public的,才能被外部對象所調用。
子類需要繼承父類去擴展父類的基本方法，但是它也可以覆寫父類的方法。如果子類去覆寫了父類的模板方法，從而改變了父類控制的頂級邏輯，這違反了“開閉原則”。我們在使用模板方法模式時，應該總是保證子類有正確的邏輯。所以模板方法應該定義為final的。所以AbstractClass類的模板方法templateMethodProcess方法應該定義為final。
模板方法模式中,抽象類的模板方法應該聲明為final的。因為子類不能覆寫一個被定義為final的方法。從而保證了子類的邏輯永遠由父類所控制。