策略模式：
用乙個排序來說一下策略模式：
常用七種：
氣泡排序
選擇排序
插入排序
希爾排序
快速排序
歸併排序
堆排序用乙個排序的例項來解釋策略模式：
/*** 用陣列排序抽出策略模式
* @author 向平**/
public class xpsortedutil }}
xpprint(arr);
}private static void swap(int arr,int i, int j)
public static void xpprint(int arr) }}
以上是寫了乙個int陣列的排序。如果要乙個double型別的排序，那麼我們必須要新增乙個double陣列排序的方法。
double的排序省略了。。。。
如果要寫car類陣列的排序，那我們就是寫乙個car陣列的排序。
/*** 用陣列排序抽出策略模式
* @author 向平**/
public class xpsortedutil }}
xpprint(arr);
}private static void swap(car arr,int i, int j)
}看到這裡大家都發現了，這樣寫下去不得了。。。。。
這樣的話有多少類，那就有多少排序方法，那你寫的這個排序工具類，簡直就沒法去維護和相容
這樣的情況我們該怎麼辦呢？？？？
我們能不能訂一套排序的統一規則呢？
當然可以，既然說到了定製統一規則，那我們一下子就會想到介面，沒錯，就是介面。
好，既然我們想到用介面來定義乙個統一排序的規則，那我們就定義個xpcomparable介面把：介面中有乙個compareto方法
************重點來了***************
xpcomparable定義好了以後，叫要進行排序的類實現它。然後根據不同類排序的規則，隨意自定義規則。
然後在排序工具類中呼叫的時候，用xpcomparable的引用去實現多型。用xpcomparable的引用去呼叫compareto方法，
傳入的是什麼類的型別陣列，就會呼叫該類中自定義實現的compareto方法進行比較。
比如：汽車類實現了xpcomparable介面，那汽車就可以比較大小了
public class car implements xpcomparable
public car(string type, int money)
public string gettype()
public void settype(string type)
public int getmoney()
public void setmoney(int money)
@override
public int compareto(object obj) throws exception else if (this.getmoney()==objcar.getmoney()) else
}else}}
排序工具類也需要變動一下：
public class xpsortedutil }}
xpprint(arr);
}private static void swap(int arr,int i, int j)
public static void xpprint(int arr)
}/**
* 這個就是滿足所有型別的排序，只要這個類實現了xpcomparable介面，也就是說只要自定義類遵循了排序規則，就可以排序
* @param arr
*/public static void sort(object arr)
} catch (exception e) }}
}private static void swap(object arr, int x, int y)
}以上這麼多的好處是什麼嗎？
就是你要怎麼排序，就可以在自己類裡面定具體規則，我要根據什麼方式排序。
比如：我有個學生類，實現了xpcomparable介面了，我就可以在compareto方法中寫排序具體的規則了，如果現在我是按照學號排序，
可能下次我的需求變了，你就直接在你的學生類的compareto方法中修改排序規則即可，不會對其他的有任何影響。
大家慢慢體會一下這種設計的好處。
小結一下：說了這麼多有提到了多型，沒錯多型才是物件導向的核心，多型是你系統或專案後期擴充套件和維護的重要手段之一。
設計模式是什麼？
其實就是把簡單的東西複雜化，沒錯是這樣。那為嘛要複雜化呢？是為了適應你後期的專案需求，多型是設計模式中乙個非常重要的組成部分。但是在使用設計模式時也不要前期設計的過度複雜，適用就可以了
因為你的設計是隨專案的增進而調整。不要為了設計而設計喔。。。。
大家別急，還沒到策略設計模式。。。萬里長城才第一步。。。。
上面雖然解決了為統一比較定義規則，然後也是實現了所有類的排序，但是真沒有問題嗎？？？？
1.雖然把排序規則可以定在所有排序類的內部，根據自己的排序需求來定製。但是如果某一天我想要修改排序的具體規則。那是不是又得去動我們已經寫好的**。
如：假設我現在有個學生類，學生類裡有：學號，年齡，學分，體重，身高
1>.那我當前是按照學號寫的排序規則，那下次如果我要以年齡來排序，我是不是要動已經寫好的**。
2>.好，我就當你改好了，但是如果有一天又變了，你是不是又要去改規則，那周而復始，你就見鬼了。。。太麻煩了，
3>.為什麼會這樣呢？？？ 那是因為你的排序規則和你的學生類之間設計的耦合度太高了。應該解耦。
怎麼解耦呢？？？
2.我們可以把排序的具體排序規則把它從具體類中剝離出去。好，沒錯就是這個思路。我們剝離出來的東西叫 "比較器" 吧
3.具體排序規則也太多了，也就意味著你的比較器也很多，我們也必須要統一下來，使用多型。不然，你又乙個噩夢開始了，如果學生類中有 "學號比較器"，"年齡比較器"，"學分比較器"，"體重比較器"，"身高比較器"
如果不要父類，其實和你上面沒有太大的優化，只是把**剝離了而已。你還得不斷的修改 比較器物件。所以我們為所有的比較器頂乙個統一的規則，比較器介面。
4.我們就定義乙個比較器介面把：comparator介面：介面中有：compare(object o1,object o2)介面
寫一段**理一下思路：
比較器介面：
/*** 比較器介面
* @author 向平**/
public inte***ce xpcomparator
比較器實現：
/*** 學生具體按學分比較的比較器
* @author 向平**/
public class studentscorecomparator implements xpcomparatorelse if (student1.getscroce()return -1;
}return 0;}}
使用比較器：
package com.xp.strategy;
/*** 學生類
* @author 向平**/
public class student implements xpcomparable
public student(string name, int age, double scroce)
public string getname()
public void setname(string name)
public int getage()
public void setage(int age)
public double getscroce()
public void setscroce(double scroce)
public xpcomparator getcomparator()
public void setcomparator(xpcomparator comparator)
/*** 開始比較
*/@override
public int compareto(object obj) throws exception
}說了這麼多，其實比較器就是使用了策略模式。
也就是說，我要排序的時候，我只要定乙個策略就可以了。不同的策略就會有不同的結果。
java 23種設計模式 08策略模式
策略模式 strategy模式也叫策略模式是行為模式之一，它對一系列的演算法加以封裝，為所有演算法定義乙個抽象的演算法介面，並通過繼承該抽象演算法介面對所有的演算法加以封裝和實現，具體的演算法選擇交由客戶端決定 策略 strategy模式主要用來平滑地處理演算法的切換 策略 演算法 抽象。各種策略 ...
Java23種設計模式
定義 設計模式 design pattern 是一套反覆使用 多數人知曉的 經過分類編目的 設計經驗的總結。使用設計模式是為了可重用 讓 更容易被他人理解 保證 可靠性。單例模式，特點 全域性只有乙個例項。定義 單例模式，也叫單子模式，是一種常用的軟體設計模式。在應用這個模式的時候，單例物件的類必須...
Java23種設計模式
建立型模式，共五種 工廠方法模式 抽象工廠模式 單例模式 建造者模式 原型模式。結構型模式，共七種 介面卡模式 裝飾器模式 模式 外觀模式 橋接模式 組合模式 享元模式。行為型模式，共十一種 策略模式 模板方法模式 觀察者模式 迭代子模式 責任鏈模式 命令模式 備忘錄模 式 狀態模式 訪問者模式 中...