設計模式的思想

如今框架能提供的服務愈來愈豐富，工程師在處理的時候，會愈來愈關心框架的邏輯，不少工程師可能只考慮如何使用框架，而不去考慮框架爲何這樣設計，這也是致使不少工程師作了好久的開發，依然仍是在作開發的緣由。

俗話說：數據結構，算法和設計模式是工程師的三件法寶。熟練掌握和使用是在之後的工做和學習過程當中能夠作到事半功倍，也是工程師進階的必要條件之一。咱們就從三件法寶之一的設計模式開始個人第一篇技術博客。

（寫這篇文章以前，我有不少擔心，我只是平凡的互聯網從業者中的一員，我擔憂寫的不夠好，誤導讀者；可是我鑑定寫這篇文章就像我第一篇文章寫的，主要是交流學習~）

爲何使用設計模式？

咱們舉個例子：小明是一名產品經理，小剛是一名開發人員，有一天小明找小剛溝通
小米：我有一個簡單的須要（嗯，簡單的需求~），我想發一篇文章，用戶打開應用的時候就能看到;
小剛：簡單，安排~

小剛一頓操做，半個小時候後，
小剛：小明，開發完了，你測試下~

五分鐘後，小明測試完
小明：我想加一個推送的功能，文章發佈以後，推送給用戶看~
小剛：安排~（心裏OS:早幹嗎了）

小剛又是一頓操做，半個小時候後，
小剛：小明，功能加完了，你再測試下~

五分鐘後，小明測試完了
小明：小剛，推送能夠用，可是我以爲不完整，我想。。。
這時候小剛拿出了40m的大刀，說道：你知道我改這個功能須要改多少代碼嗎？你能不能把邏輯想清楚~

對話END~~~~

我以爲這例子是現實中比較常見的例子，這說明了代碼的可擴展性差、複用性差，耦合度高等問題，這時候就須要用到設計模式。

什麼是設計模式？

不是牛頓說的的一句話：「若是我看得更遠一點的話,是由於我站在巨人的肩膀上」。

設計模式（Design Pattern）是一套被反覆使用、多數人知曉的、通過項目實戰的開發經驗的總結（對，就是總結，踩在巨人的肩膀上）。而且這套總結，能夠實現代碼代碼的高可擴展性、高複用性和鬆耦合等功能。

掌握設計模式以後，將提升一下能力：
1.代碼能力的加強；
2.節省溝通成本，一句話：這個功能使用xxx模式實現的，你你應該明白的程序的執行邏輯了；
3.閱讀源碼能力的提升，大師就是大師，這個模式的我明白；
。。。。。。。

設計模式的原則

設計模式的原則也是面向對象編程的原則，面向對象編程和麪向過程編程主要的是編程思想的不一樣：面向過程是對實現過程進行邏輯編程；面向對象是對實現過程當中所用的對象的組合（有點繞~）。

舉個栗子：
小明要從車站買票去北京~
面向過程思想：小明要先去車站 -》買票 -》上車 -》 下車
面向對象思想：把過程當中使用的工具抽象成對象：車站 車票 車，而後把這些對象進行組合，小明就到北京了。

三大基本特性：封裝，繼承，多態

封裝

把客觀事物封裝成抽象的類，而且類能夠把本身的數據和方法只讓可信的類或者對象操做，對不可信的進行信息隱藏。一個類就是一個封裝了數據以及操做這些數據的代碼的邏輯實體。

繼承

它可使用現有類的全部功能，並在無需從新編寫原來的類的狀況下對這些功能進行擴展。 經過繼承建立的新類稱爲「子類」或「派生類」，被繼承的類稱爲「基類」、「父類」或「超類」。繼承的過程，就是從通常到特殊的過程。

多態

一個類實例的相同方法在不一樣情形有不一樣表現形式。多態機制使具備不一樣內部結構的對象能夠共享相同的外部接口。

五大基本原則

單一職責原則SRP(Single Responsibility Principle)

是指一個類的功能要單一，不能一應俱全。如上面例子，車站就負責賣票和上下車，不能具備車行駛的功能。

開放封閉原則OCP(Open－Close Principle)

一個模塊在擴展性方面應該是開放的而在更改性方面應該是封閉的。仍是上面的例子，如今我要增長坐飛機去北京的功能，在增長這個功能的時候，不能影響坐車去北京（對擴展是開放的）；若是小米以爲車站的服務太差，想要增長車站工做人員的數量，那是不可能（對修改是封閉的）。

里氏替換原則LSP(the Liskov Substitution Principle LSP)

子類應當能夠替換父類並出如今父類可以出現的任何地方。仍是上面的列子（假設同窗們已經理解繼承的概念了），小明想此次作火車去北京，下次坐汽車去北京，火車站和汽車站都繼承了車站這個基類，那麼小明就能夠選擇汽車和火車進行出行了，而不該該只限於火車或者汽車。

依賴倒置原則DIP(the Dependency Inversion Principle DIP)

具體依賴抽象，上層依賴下層。假設B是較A低的模塊，但B須要使用到A的功能，這個時候，B不該當直接使用A中的具體類：而應當由B定義一抽象接口，並由A來實現這個抽象接口，B只使用這個抽象接口：這樣就達到了依賴倒置的目的，B也解除了對A的依賴，反過來是A依賴於B定義的抽象接口。經過上層模塊難以免依賴下層模塊，假如B也直接依賴A的實現，那麼就可能形成循環依賴。

迪米特原則LOD(Law of Demeter LOD)

迪米特法則又叫作最少知識原則（Least Knowledge Principle, LKP）

因爲每一個對象儘可能減小對其餘對象的瞭解，所以，很容易使得系統的功能模塊功能獨立，相互之間不存在（或不多有）依賴關係。

接口分離原則ISP(the Interface Segregation Principle ISP)

模塊間要經過抽象接口隔離開，而不是經過具體的類強耦合起

設計模式的分類

範圍 建立型 結構型 行爲型

範圍	建立型	結構型	行爲型
類	Factory Method（工廠方法）	Adapter(類) （適配器）	Interpreter（解釋器） Template Method（模版方法）
對象	Abstract Factory（抽象工廠）Builder（建造者）Prototype（原型）	Bridge（橋接）Composite（組合） Decorator（裝飾者） Facade（外觀）Flyweight（享元）Proxy（代理）	Chain of Responsibility（職責鏈） Command（命令） Iterator（迭代器） Mediator（中介者） Memento（備忘錄） Observer（觀察者） State（狀體） Strategy（策略） Visitor（訪問者）

沒有哪一種模式是完美的，實際開發過程當中，咱們須要根據不一樣的需求來使用相應的模式，這樣才能體現出高內聚，低耦合的好處；仍是開頭說過的，設計模式是經驗的總結，熟練使用設計模式不只僅能提升本身的效率，熟能生巧，在現實生活也有意義。