這系列博文將先講述七大設計模式的原則，再詳述23種java設計模式。
博文皆是東拼西湊而成，若有錯誤，還望指出。
一、設計模式的目的
在代碼編寫的過程中，面臨着代碼耦合、內聚等問題，同時優質代碼應該有很好的拓展性、複用性、可靠性、可讀性（規範性）。設計模式包含了面向對象編程的精髓思想，使得代碼呈現出
1）高內聚（相關度比較高的部分儘可能的集中，不要分散）
2）低耦合（模塊之間儘可以能把依賴的部分降低到最小）
，同時也具有更好怕的代碼複用性和可讀性。
二、設計模式六大原則
SOLID+迪米特法則，最後額外加了一種
1）單一職責原則（Single-Resposibility Principle）
定義：A class should have a single responsibility, where a responsibility is nothing but a reason to change.（一個類應該有一個單一的職責，其中職責是唯一改變這個類的理由。）
含義：當設計某個模塊的時候，我們應該留意，一個類最多爲一類任務或者功能負責，並且當且僅當這類任務或者功能需要變動時，這個類才能發生變動。這樣，類就會有高內聚特性。
比如，在設計一個員工類的時候，
public class Employee{
private String employeeId;
private String name;
private string address;
private Date dateOfJoining;
public boolean isPromotionDueThisYear(){
//promotion logic implementation
}
public Double calcIncomeTaxForCurrentYear(){
//income tax logic implementation
}
//Getters & Setters for all the private attributes
}
上面的Employee類在邏輯上看起來正確。它具有員工所有的屬性，如employeeId，name，age，address和dateOfJoining。它甚至會告訴您該員工今年是否有資格晉升，並計算出該年度他必須支付的所得稅。
但是，Employee類違反了單一責任原則。讓我們看看是怎麼回事 –
- 確定員工是否應於今年晉升的邏輯實際上不是員工應承擔的責任。公司的人力資源部門根據公司的人力資源政策（這可能每幾年更改一次）承擔此責任。在人力資源政策上的任何更改，都將需要更改Employee類。
- 同樣，所得稅的計算也不是員工的責任。財務部門負責處理當前的稅收組成，該組成可能每年都會更新。如果員工類擁有所得稅計算責任，那麼每當稅制計算方法發生變化時，都將需要更改員工類別。
- 最後，
Employee類應承擔維護員工核心屬性的單一責任。
那麼使用單一責任原則應該怎麼做呢？
首先判斷員工是否晉升應該是HR的工作，所以應該分開一個類
public class HRPromotions{
public boolean isPromotionDueThisYear(Employee emp){
//promotion logic implementation using the employee information passed
}
}
再者就是計算稅收的財務類
public class FinITCalculations{
public Double calcIncomeTaxForCurrentYear(Employee emp){
//income tax logic implementation using the employee information passed
}
}
最後是Employee的核心屬性類
public class Employee{
private String employeeId;
private String name;
private string address;
private Date dateOfJoining;
//Getters & Setters for all the private attributes
}
再舉一個例子，比如設計商城用戶類，用戶擁有優惠券，用戶類這樣設計
public class User {
private String id;
private String name;
//more attributes
//獲取用戶優惠券
public List<Coupon> findUserCouponList(String id) {
//implements detail
}
}
從邏輯上來說，並沒有錯誤，但是如果優惠券有變動的時候，比如更改優惠券類名，更改獲取優惠券方式等等，那麼User類也要隨着更改，這就違反了單一職責原則。用戶類應該只包含用戶屬性，優惠券功能應該由專門的類處理。
所以應該這樣更改
用戶類
public class User {
private String id;
private String name;
//more attributes
}
優惠券服務類
public class CouponServiceImplement {
//獲取用戶優惠券
public List<Coupon> findUserCouponList(String id) {
//implements detail
}
}