Java[Design Pattern設計模式]策略模式(Strategy Pattern)

今天假設我要設計一個排序的程式

那至於排序的方法我希望能夠有三種方法:

1.Bubble Sort

2.Quick Sort

3.Merge Sort

那我們的程式可能會這樣寫

▲我利用了switch case去選擇我要排序的方法，

而至於排序實作方法則交給BubbleSort(),QuickSort(),MergeSort(){} 自己去完成

這邊我並沒有把每個排序方法的程式寫出來，各位朋友可以自行補上

▲在這邊我利用enum去定義我的三個排序方法

這種寫程式的方法出了什麼問題?

1.不易擴充:

   如果今天我希望新增一種排序方法叫做Selectiont Sort，那麼我就必須去改我的switch case

因此違反了OO設計原則中的Open-Closed Principle

2.我的Algorithm這支程式會容易變得太大:

  如果我要再加入一個新的排序方法，那我下面就必須再寫一個method去實作這個方法

因為我現在並沒有將這些排序方法的程式碼寫出來，所以不太有感覺

各位朋友如果要體驗這個force的話，可以把程式寫出來，即便是Pseudo code都能體會到

那我們該怎樣讓我們的設計更好呢?

這裡就要談到Design Pattern中的Strategy Pattern

Define a family of algorithm, encapsulate each one, and make them interchangeable.

Strategy lets the algorithm very independently from clients that use it. 《GoF》

策略模式定義了演算法家族，個別封裝起來，讓他們之間可以互相替換，使模式讓演算法的變動，

不會影響到使用演算法的程式。

接下來我們就把Stratege pattern套用在我們的例子中

首先，先定義我們的Stratege 介面

接著，我們開始實作Concrete Stratege

▲Bubble Sort

▲Quick Sort

▲Merge Sort

再來，我們要實作Context，也就是改一下我們原本的Algorithm

▲在這個程式中，我希望使用者只要輸入他們要用的排序方式

createSort主要是要幫我們把使用者輸入的排序方式然後把我們的Concrete Strategy 的Instance new出來

這種寫法主要想避免以下這種寫法

▲這種寫法當然也可以，但還是一樣老問題，違反了OCP

最後，我們就可以測試一下我們的程式是否正常運作了

到後來我們的class diagram就變成這樣了

當我們的程式要用不同的作法或方法去完成一件事情時我們才會討論Strategy pattern是否對我們的設計有幫助