雖然有過三年的開發經歷，但是還是小菜一枚，在大鳥的指導下，開始專業化進入軟體這條道路。 首先大鳥推薦第一本書籍，就是《大話設計模式》。一邊做筆記一邊看書，書中以身邊的故事，引出6種設計原則&23種設計模式。 歷練使人成長，經驗迸發靈感。然而所有的靈感都應有其因，那就是萬變不離其宗的六大面向對象的設計 ...
雖然有過三年的開發經歷，但是還是小菜一枚，在大鳥的指導下，開始專業化進入軟體這條道路。
首先大鳥推薦第一本書籍，就是《大話設計模式》。一邊做筆記一邊看書，書中以身邊的故事，引出6種設計原則&23種設計模式。
歷練使人成長，經驗迸發靈感。然而所有的靈感都應有其因，那就是萬變不離其宗的六大面向對象的設計原則，即單一職責原則、開放--封閉原則、依賴倒轉原則、里氏代換原則、迪米特法則和合成--聚合復用原則。但這六大原則僅僅是一系列的“口號”，真正付諸實施還需要有詳盡的指導方法，於是23種設計模式應運而生。歸根到底，就是通過重構改善既有代碼，使代碼的耦合度降低，最終實現易維護、易擴展、易復用和靈活性好的編程設計，得到精彩的代碼。
寫這篇文章的主要目的，是為了記錄我此時的學習狀態和心得，以便日後回顧。同時也為正在軟體行業彷徨的小伙伴們指點路途。
一.六種設計原則（核心：強內聚，松耦合）
1.單一職責原則
Story：手機功能齊全，但一在關鍵時刻就“萎”掉；
Concept：就一類而言，應該只有一個引起它變化的原因，體現了類的職責分離。
Tips：如mvc架構，實現邏輯和界面的分離。
2.開放--封閉原則
Story：考研&找工作兩手抓，香港澳門一國兩制；
Concept：是所有面向對象原則的核心。軟體實體應該是可擴展，而不可修改的。即對擴展是開放的，而對修改是封閉的。
Tips：應該僅對程式中呈現出頻繁變化的那些部分做出抽象，拒絕不成熟的抽象和抽象本身一樣重要。
3.依賴倒轉原則
Story：修電腦門檻低，因為PC電腦的主板、CPU和記憶體等針對介面設計，而不是針對實現設計，耦合程度低，依賴性弱，易維修；而收音機過多強耦合開發，難排查，難維修；
Concept：高層模塊不應該依賴低層模塊，兩者都應該依賴其抽象；抽象不應該依賴細節，細節應該依賴抽象；
Tips：（1）應針對介面編程，不要對實現編程；因為針對實現來設計記憶體，就要對應到具體的某個品牌的主板，那會出現換記憶體需要把主板也換了的尷尬；
（2）依賴倒轉原則其實是面向對象設計的標誌。若編寫時考慮的都是針對抽象編程即為面向對象設計；反之，針對細節編程即為過程化的設計；
4.里氏代換原則
Story：繼承關係，如鳥類&企鵝類；
Concept：在軟體中，把父類都替換成它的子類，而程式的行為沒有變化。子類型必須能夠替換他們的父類型；正是由於子類型的可替換性才使得使用父類型的模塊在無需修改的情況下就可以擴展；
Tips：里氏代換原則是對開放--封閉原則的補充。實現開放--封閉原則的關鍵步驟就是抽象化。而基類與子類的繼承關係就是抽象化的具體實現，所以里氏代換原則是對實現抽象化的具體步驟的規範。
5.迪米特法則
Story：無熟人難辦事，主要是處理許可權問題；
Concept：也叫最少知識原則。類之間的耦合越弱，就越有利於復用，一個處在弱耦合的類被修改，不會對有關係的類造成波及。 主要是強調了類之間的松耦合；
Tips：在類的設計上，每一個類都應當儘量降低成員的訪問許可權。
6.合成--聚合復用原則
Story：硬體廠商生產的硬體與軟體廠商生產的軟體為合成關係；手機品牌包含的手機軟體為聚合關係；
Concept：合成聚合是“has a”的關係，而繼承是“is a”的關係。由於繼承是一中強耦合的結構，父類變，子類必變。所以不是“is a”關係，我們一般不要用繼承。優先使用合成聚合復用原則，有助於保持每個類的封裝，降低繼承的層次。
Tips：儘量使用合成/聚合，儘量不使用類繼承。
二. 23種設計模式
A.創建型模式
1.簡單工廠模式
Story：計算器的功能設計與實現；
Concept：又叫做靜態工廠方法模式，是由一個工廠對象決定創建出哪一種產品類的實例；
Tips：提供一個創建一系列或相關依賴對象的介面，而無需指定它們具體的類。
2.建造者模式
Story：炒麵沒放鹽，千家千味，而肯德基麥當勞千家一味；建造小人物；
Concept：將一個複雜對象的構建與它的表示分離，使得同樣的構建過程可以創建不同的表示。用戶只需要指定建造的類型，而無需知道具體建造的過程與細節。
Tips：Builder介面的對象是用於創建一些複雜的對象，這些對象內部構建間的建構順序通常是穩定的，但對象內部的構建通常面臨著複雜的變化。其好處就是，使建造代碼與表示代碼分離。
3.工廠方法模式
Story：學雷鋒，不留名，志願者愛心行動相傳。
Concept：定義一個用於創建對象的介面，讓子類決定實例化哪一個類。工廠方法使一個類的實例化延遲到其子類。
4.原型模式
Concept：用原型實例指定創建對象的種類，並且通過拷貝這些原型創建新的對象；
Tips:主要用於對象的複製，它的核心是就是類圖中的原型類Prototype。使用原型模式的一個好處是簡化對象的創建，使得創建對象就像我們在編輯文檔時的複製粘貼一樣簡單。
5.單例模式
Concept：保證一個類僅有一個實例，並提供一個訪問它的全局訪問點。
Tips：單例模式可讓類自身負責保存它的唯一實例。
B.結構型模式
6.適配器模式
Story：姚明在NBA需要翻譯；
Concept：將一個類的介面適配成用戶所期待的。包括類適配器模式和對象適配器模式；
Tips：主要應用於希望復用一些現存的類，但是介面又與復用環境要求不一致的情況。只有在無法改變原有設計和代碼的情況下才考慮適配；
7.橋接模式
Story：手機品牌不統一，軟體不相容；
Concept：將抽象部分與它的實現部分分離，使他們都可以獨立地變化。
8.組合模式
Story：為有分銷機構的大公司做辦公管理系統；
Concept：將對象組合成樹形結構以表示“部分——整體”的層次結構。組合模式使得用戶對單個對象和組合對象的使用具有一致性；
Tips：使用條件為：當需求中體現部分與整體層次的結構時，以及你希望用戶可以忽略組合對象與單個對象的不同，統一地使用組合結構中的所有對象時；
9.裝飾模式
Story：穿何種服裝見女朋友；
Concept：每個裝飾對象的實現和如何使用這個對象分離開；
Tips：這樣做的最大好處就是有效地把類的核心職責和裝飾功能區分開，而且可以去除相關類中重覆的裝飾邏輯。
10.外觀模式
Story：股票投資風險大，眾多投資者與眾多股票聯繫太多，反而不利於操作；而基金是基金經理人與上千股票和其他投資產品打交道，風險更小；
Concept：為子系統中的一組介面提供一個一致的界面，此模式定義了一個高層介面，這個介面使得這一子系統更加容易使用；
Tips：使用情況：（1）在設計初期階段，應該要有意識地將不同的兩個層分離；（2）在開發階段，子系統往往因為不斷的重構演化而變得越來越複雜。若增加Façade可以提供一個簡單的介面，以減少它們之間的依賴性；（3）在維護一個遺留的大型系統時，可能這個系統已經非常難以維護和擴展，這時，可以為新系統開發一個Façade類，來提供設計粗糙或高度複雜和遺留代碼比較清晰的介面，讓新系統與Façade對象交互，Façade與遺留代碼交互所有複雜的工作；
11.亨元模式
Concept：以共用的方式高效地支持大量的細粒度對象；
Tips：1）享元模式使得系統更加複雜。為了使對象可以共用，需要將一些狀態外部化，這使得程式的邏輯複雜化；
12.代理模式
Story：卓賈易通過戴勵送嬌嬌東西，結果戴勵與嬌嬌戀愛了；
Concept：在訪問對象時引入一定程度的間接性，因為這種間接性，可以附加多種用途。
Tips：代理模式包括：遠程代理、虛擬代理、安全代理和智能指引；
C.行為型模式
13. 觀察者模式
Story：上班炒股，前臺秘書通風報信；要求前臺類與觀察者雙向耦合；
Concept：定義一種一對多的關係，讓多個觀察者對象同時監聽某一主題對象；
Tips：當不知道具體有多少對象有待改變時，應該考慮使用觀察者模式。實則在解耦合，讓耦合雙方都依賴於抽象，而不是依賴於具體；
14.模板方法模式
Story：看不懂英文試題，會做也白搭；
Concept：：在一個方法中定義一個演算法的骨架，而將一些實現步驟延遲到子類中。模板方法使得子類可以在不改變演算法結構的情況下，重新定義演算法中的某些步驟；
15.命令模式
Story：打游擊烤羊肉串的檔口對請求排隊或記錄請求日誌以及支持可撤銷操作，其實是“行為請求者”與“行為實現者”的緊耦合；做烤肉的開門店反之；
Concept：將一個請求封裝一個對象，從而使你可用不同的請求對客戶進行參數化，對請求排隊或記錄請求日誌以及支持可撤銷操作；
Tips：敏捷開發原則；
16.狀態模式
Story：不同時間人的精神狀態不同；
Concept：當一個對象的內在狀態改變時允許改變其行為，這個對象看起來像是改變了其類。
Tips：狀態模式主要解決的是當控制一個對象狀態的條件表達式過於複雜時的情況。把狀態的判斷邏輯轉移到表示不同狀態的一系列類中，可以把複雜的判斷邏輯簡化。其好處是，將與特定狀態相關的行為局部化，並且將不同狀態的行為分割開來；
17.職責鏈模式
Story：設計加薪代碼；
Concept：使多個對象都有機會處理請求，從而避免請求的發送者和接受者之間的耦合關係。將這個對象連成一條鏈，並沿著這條鏈傳遞該請求，直到有一個對象處理他為止。
18.解釋器模式
Story：明白老闆的評價背後潛臺詞；
Concept：如果一個特定類型的問題發生的頻率足夠高，那麼可能就值得將該問題的各個實例表述為一個簡單語言中的句子；
Tips：可構建一個解釋器通過解釋這些句子來解決該問題；
19.中介者模式
Story：安理會&聯合國等調停組織；
Concept：又叫調停者模式，定義一個中介對象來封裝系列對象之間的交互。中介者使各個對象不需要顯示地相互引用，從而使其耦合性鬆散，而且可以獨立地改變他們之間的交互。
20.訪問者模式
Story：man & woman的異同；
Concept：表示一個作用於某對象結構中的各元素的操作。它使你可以在不改變各元素類的前提下定義作用於這些元素的新操作。
Tips：目的是把處理從數據結構中分離出來；
21.策略模式
Story：商場促銷中各種折扣優惠的實現；
Concept：定義了一系列的演算法，並將每一個演算法封裝起來，而且使它們還可以相互替換，讓演算法獨立於使用它的客戶而獨立變化；
Tips：優點是：簡化了單元測試；
22.備忘錄模式
Story：游戲存儲進度；
Concept：在不破壞封閉的前提下，捕獲一個對象的內部狀態，併在該對象之外保存這個狀態。這樣以後就可將該對象恢復到原先保存的狀態。
Tips：涉及角色：發起人(Originator)、備忘錄(Memento)和管理者(Caretaker)；
23.迭代器模式
Story：售票員進行迭代遍歷檢票，不放過漏網之魚；
Concept：提供一種方法順序訪問一個聚合對象中各個元素，而又不需暴露該對象的內部表示；
Tips：分離了集合對象的遍歷行為，抽象出一個迭代器類來負責，這樣既可以做到不暴露集合的內部結構，又可以讓多部代碼透明地訪問集合內部的數據；
