一、設計模式的概念

什麼是好的軟體設計？—— 複用！
◆  首先我們要先理解一個問題，什麼是模式？ 

每一個模式描述了一個在我們周圍不斷重複發生的問題，以及該問題的解決方案的核心。這樣，你就能一次又一次地使用該方案而不必做重複勞動。 

◆  設計模式：也就是為了使程式碼的可複用，減少不必要的勞動；通常情況下，我們講的設計模式隱含地表示“面向物件設計模式”。（其中 可複用是目標，面向物件是手段，這兩點是設計模式的核心。）

二、面向物件的設計模式

變化是複用的天敵！面向物件設計最大的優勢 —— 抵禦變化！

(一)  “元件協作”模式

現代軟體專業分工之後的第一個結果是“框架與應用程式的劃分”，“元件協作”模式通過晚期繫結，來實現框架與應用程式之間的鬆耦合，是二者之間協作時常用的模式。

1.  Template Method模板方法

定義一個操作中的演算法的骨架，而將一些步驟延遲到子類中。Template Method使得子類可以不改變一個演算法的結構即可重定義（override重寫）該演算法的某些特定步驟。 初始程式碼：

//程式庫開發人員
class Library {

    //穩定
    public void step1() {
        //...
    }

    //穩定
    public void step3() {
        //...
    }

    //穩定
    public void step5() {
        //...
    }

}

//應用程式開發人員
class Application {

    //變化
    public boolean step2() {
        //...
        return true;
    }

    //變化
    public void step4() {
        //...
    }

    //穩定
    public static void main(String args[]) {


        Library lib = new Library();

        Application app = new Application();

        lib.step1();

        if (app.step2()) {
            lib.step3();
        }

        for (int i = 0; i < 4; i++) {
            app.step4();
        }

        lib.step5();
    }

}
 

優化程式碼：

//程式庫開發人員
abstract class Library {
    public void run() {//穩定 template method

        step1();
        if (step2()) {//支援變化 ==> 虛擬函式的多型呼叫
            step3();
        }

        for (int i = 0; i < 4; i++) {
            step4();//支援變化 ==> 虛擬函式的多型呼叫
        }

        step5();
    }


    protected void step1() {//穩定
        //...
    }

    protected void step3() {//穩定
        //...
    }

    protected void step5() {//穩定
        //...
    }

    abstract boolean step2();//變化

    abstract void step4();//變化
}
 

//應用程式開發人員
class Application extends Library {

    @Override
    protected boolean step2() {
        //... 子類重寫實現
        return true;
    }

    @Override
    protected void step4() {
        //... 子類重寫實現
    }

    public static void main(String args[]) {

        Library lib = new Application();
        lib.Run();

    }

}

使用Template模式優化後，將本來要寫在應用程式程式碼中演算法骨架提前新增到程式庫中來，而應用程式開發人員只需要override重寫方法即可。 ◆  要點總結：
        ●  它用最簡潔的機制（虛擬函式的多型性）為很多應用程式框架提供了靈活的擴充套件點，是程式碼複用方面的基本實現結構；         ●  除了可以靈活應對子步驟的變化外，“不要呼叫我，讓我來呼叫你”的反向控制結構是Template的典型應用；         ●  在具體實現方面，被Template呼叫的虛方法可以具有實現，也可以沒有任何實現（抽象方法、純虛方法），但一般推薦將它們設定為protected方法。

2.  Strategy策略模式

◆  動機：         在軟體構建過程中，某種物件使用的演算法可能多種多樣，經常改變，如果將這些演算法都編碼到物件中，將會使物件變得異常複雜；而且有時候支援不使用的演算法也是一種效能負擔。如何在執行時根據需要透明的更改物件的演算法？將演算法與物件本身解耦，從而避免上述問題？ 初始程式碼：

public enum TaxBase {
    CN_Tax,
    US_Tax,
    DE_Tax,
    FR_Tax, //更改
};

public class SalesOrder{

    TaxBase tax;

    public void calculateTax(){

        //...

        switch(tax){
            case CN_Tax:
                //CN***********
                break;
            case US_Tax:
                //US***********
                break;
            case De_Tax:
                //DE***********
                break;
            case FR_Tax:  //更改
                //FR***********
                break
        }


        //....
    }

}

上述程式碼中，如果要增加一個選項，需要在兩處進行更改； 優化程式碼：

abstract class TaxStrategy{
    public abstract double Calculate(Context context);
}

public class CNTax extends TaxStrategy{

    @Override
    public double Calculate(Context context){
        //......
    }

}

public class USTax extends TaxStrategy{

    @Override
    public  double Calculate(Context context){
        //******
    }
}

public class DETax extends TaxStrategy{

    @Override
    public  double Calculate(Context context){
        //######
    }
}

//擴充套件
public class FRTax extends TaxStrategy{

    @Override
    public  double Calculate(Context context){
        //######
    }
}



public class SalesOrder{

    TaxStrategy strategy;

    public SalesOrder(TaxStrategy strategy){
        this.strategy=strategy;
    }


    public double CalculateTax(){
        //...
        Context context;

        double val=strategy.Calculate(context);//多型呼叫
        //...

    }

}

        優化後，好處有兩點：1. 只需要擴充套件一個FRtext選項即可，主題演算法是不需要改變的；2. 初始程式碼中，編譯器要編譯所有的程式碼，即使有些case裡的選項是用不到的。優化後，利用抽象類的多型性，只有需要的選項才會被例項化進行編譯，這樣能夠節省CPU的應用空間。 ◆  模式定義：         定義一系列演算法，把它們一個個封裝起來，並且使它們可互相替換。該模式使得演算法可獨立於使用它的客戶程式而變化（擴充套件，子類化）。在上例中，我們用類來封裝每一個演算法，然後建立一個基類的統一的介面。通過介面，當需要哪一個演算法時就呼叫哪個演算法。當需求變更時，我們只需要擴充套件一個子類即可。其中，客戶程式就是SaleOrder（）方法，演算法改變，但客戶程式不需要改變。 ◆  要點總結：         ●  Strategy及其子類為元件提供了一系列可重用的演算法，從而可以使得型別在執行時方便的根據需要在各個演算法之間切換；         ●  Strategy模式提供了用條件判斷語句以外的另一種選擇，消除條件判斷語句，就是在解耦和。含有很多條件判斷語句的程式碼通常需要Strategy模式；         ●  如果Strategy物件沒有例項變數，那麼各個上下文可以共享同一個Strategy物件，從而節省物件開銷。

3.  Observer觀察者模式

◆  動機：         在軟體構建過程中，我們需要為某些物件建立一種“通知依賴關係”——一個物件（目標物件）的狀態發生改變，所有的依賴物件（觀察者物件）都將得到通知。如果這樣的依賴關係過於緊密，將使軟體不能很好地抵禦變化。使用面向物件技術，可以將這種依賴關係弱化，並形成一種穩定的依賴關係。從而實現軟體體系結構的鬆耦合。

public class MainActivity extends AppCompatActivity {

    private Button mAppendButton;
    private EditText mEditText;
    private TextView mLabelText;

    private int count=0;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);


        mAppendButton = (Button) findViewById(R.id.appendButton);
        mEditText = (EditText) findViewById(R.id.contentEdit);
        mLabelText = (TextView) findViewById(R.id.countText);


        //訂閱通知
        mEditText.addTextChangedListener(textWatcher);

        //取消訂閱
        //mEditText.removeTextChangedListener(textWatcher);

        mAppendButton.setOnClickListener(clickListener);


    }


    OnClickListener clickListener = new OnClickListener() {
        @Override
        public void onClick(View v) {
            String content = mEditText.getText().toString().trim();
            //文字框內容處理
            content = content + Integer.toString(count);
            count++;
            mEditText.setText(content);
            mEditText.setSelection(content.length());//游標置於末尾
        }
    };


    TextWatcher textWatcher = new TextWatcher() {

        public void beforeTextChanged(CharSequence s, int start, int count, int after) {

            Log.i("BeforeTextChanged:", s.toString() );
        }


        public void onTextChanged(CharSequence s, int start, int before, int count) {

            Log.i("OnTextChanged:", s.toString() );
        }

        public void afterTextChanged(Editable s) {
            String count = Integer.toString(s.length());
            mLabelText.setText(count);
        }
    };

}

        上例中，我們對EditText添加了TextWatcher，檢視原始碼可以看到，這個TextWatcher是被新增到一個TextWatcher陣列中，這裡可以新增多個觀察者。並重寫了TextWatcher的三個方法。當EditText的內容發生改變時，就會通知依賴它的物件（MainActivity）執行相應的方法。上面程式碼中定義一個TextWatcher這一塊，就是一個Observer觀察者物件。需求變更時，我們也只需要改變這一塊程式碼即可。上例中，還有一個觀察者物件，就是Button的OnClickListener物件，它只觀察一個物件，所以沒有觀察者列表，這是Observer的一個弱化版。
◆  模式定義：         定義物件間一種一對多的依賴關係，以便當一個物件（Subject）的狀態發生改變時，所有依賴於它的物件都得到通知並自動更新。 ◆  要點總結：         ●  使用面向物件的抽象，Observer模式使得我們可以獨立地改變目標和觀察者，從而使二者的依賴關係達至鬆耦合；
        ●  目標傳送通知時，無需指定觀察者，通知（可以攜帶通知資訊作為引數）會自動傳播；
        ●  觀察者自己決定是否需要訂閱通知，目標物件（例子中的MAinActivity）對此一無所知；
        ●  Observer模式是基於事件的UI框架中非常常用的設計模式，也是MVC模式的一個重要組成部分；