?????? 設計模式（Design Pattern）是面向對象技術的最新進展之一，由于面向對象設計的靈活性，增加了其設計的復雜性，設計模式的出現就是為了提高復用的設計方案，讓代碼更容易被他人理解、保證代碼可靠性。設計模式于己于他人于系統都是多贏的，設計模式使代碼編制真正工程化，設計模式是軟件工程的基石，如同大廈的一塊塊磚石一樣。 ????? 要想用好設計模式，必須先明白設計模式的六大原則：單一職責原則、開放封閉原則、依賴倒轉原則、里氏代換原則、合成聚合復用原則、迪米特法則。 ### ?①?? 【單一職責原則SRP】 ?????? 單一職責原則，就一個類而言，應該僅有一個引起它變化的原因。如果一個類承擔的職責過多，就等于把這些職責耦合在一起，一個職責的變化可能會消弱或者一直這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當變化發生時，設計會遭受到意想不到的破壞。而軟件設計真正要做的許多內容，就是發現職責，并把這些職責相互分離。 ### ?②?? 【開放封閉原則OCP】 開放-封閉原則，是說軟件實體（類、模塊、函數等等）應該可以擴展，但是不可以修改。即對于擴展是開放的，對于更改是封閉的。當用戶需求的變化，不鞥輕易更改源代碼，而是應該創建抽象類，去隔離以后發生的同類變化。這樣會使得變化中的系統有一定的穩定性和延續性。 例如當年玉皇大帝在不更改現有天庭秩序的情況下，成功擴展“弼馬溫”這個秩序（類）。  ### ?③?? 【依賴倒轉原則DIP】 ?????? 抽象不應該依賴細節，細節應該依賴于抽象。即我們要針對接口（抽象類）編程，不要針對與實現編程。 ??????? 比如你開車進小區，小王是門衛，每次你到門口，喊一聲“小王，幫忙開下門”他就給你開了，但是對于剛搬進小區的小李，他可不認識小王，他怎么通知小王開門呢？假如突然有一天，門衛換了，難道你就不進小區了？答案大家都知道，只要喊“門衛，幫忙開下門”，你和小李就都可以進去了。所以不管門衛和小區的業主怎么換，只要“門衛”這個“接口”是不變，那么業主就可以讓門衛給開門。 ### ?④?? 【里氏代換原則LSP】 ?????? 里氏代換原則，子類型必須能夠替換掉他們的父類型。在軟件里面，把父類都替換成其子類，程序的行為不會發生變化。 簡單來說，子類=父類 [+新功能]。父類的非私有成員都會被子類繼承，還可以根據自身情況對繼承來的方法DIY。當用子類去實例化父類，調用父類的方法，具體實現則是剛才的子類的方法。（也就是說如果這個父類有多個子類的話，只要用不同的子類去實例化這個父類，那么這個父類對象執行相同的方法，則會執行各自子類對應的同名方法，所以結果也會不同。而這就是“多態”！所以可以說多態是里氏代換原則的體現。）當然反過來是不成立的。例如矩形和正方形，我們可以說正方形是一種特殊的矩形，但不可以說矩形是一種特殊的正方形。 ### ?⑤?? 【合成聚合復用原則CARP】 ?????? 合成聚合復用原則：盡量使用合成\聚合，盡量不使用類繼承。合成聚合是”has ?a”的關系，而繼承是“is ?a”的關系。由于繼承是一中強耦合的結構，父類變，子類必變。所以不是“is? a”關系，我們一般不要用繼承。優先使用合成聚合復用原則，可以保持每個類的封裝，降低繼承的層次。  ??????根據此原則轉變后為：  ### ?⑥?? 【迪米特法則】 ?????? 如果兩個類不必彼此直接通信，那么這兩個類就不應當發生直接的相互作用。如果其中一個類需要調用另一個類的某一個方法時，可以通過第三者轉發這個調用。類之間的耦合越弱，就越有利于復用，一個處在弱耦合的類被修改，不會對有關系的類造成波及。也就是說，一個對象對其他對象盡可能少的了解（不要和陌生人說話）。