今天假设我要设计一个排序的程式

那至于排序的方法我希望能够有三种方法:

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是否对我们的设计有帮助