設計模式（Design pattern）是一套被反復使用、多數(shù)人知曉的蕾哟、經(jīng)過分類編目的代碼設計經(jīng)驗的總結覆积。使用設計模式是為了可重用代碼、讓代碼更容易被他人理解徐紧、保證代碼可靠性静檬。 毫無疑問，設計模式于己于他人于系統(tǒng)都是多贏的并级；設計模式使代碼編制真正工程化拂檩；設計模式是軟件工程的基石脈絡，如同大廈的結構一樣嘲碧。

可以看出稻励，23種設計模式也不是憑空捏造出來的，而是經(jīng)過了反復的推敲修改以及諸多的項目實戰(zhàn)總結而出的代碼設計經(jīng)驗愈涩。因此望抽，能作為一種模式（pattern），設計模式不再是代碼的羅列履婉，而是扎實的邏輯結構煤篙，每一種設計模式都擁有成熟的思想。

設計模式的發(fā)展

既然是“模式”毁腿，那么容易得出設計模式可以應用于各種各樣的編程語言中辑奈，而且所得出的表現(xiàn)都應該是一樣的苛茂。對于一些像是C#、Java身害、C++這樣的比較明確的面向對象的語言味悄，一種設計模式在各語言之間的轉換都是比較容易的，只是語法不同而已塌鸯。但是侍瑟，JavaScript作為一種弱類型的切十分靈活的語言，甚至沒有明確的class這個關鍵字丙猬，隨著Node和HTML5以及web2.0的興起才開始受到比較多的重視涨颜，設計模式對她來講就和變得和別的語言不同。

但是茧球，很多東西Javascript都有庭瑰，只是沒有作為正式的部分。而設計模式又是一種編程的思想抢埋，思想是相同的弹灭，一旦你掌握了這種思想，代碼就可以相通揪垄，利用一些javascript的特性來實現(xiàn)各種設計模式應該也不是一件特別難的事情穷吮。

設計原則

面向對象程序設計有幾個原則：開閉原則、里氏轉換原則饥努、依賴倒轉原則捡鱼、接口隔離原則、合成/聚合復用原則酷愧、最小知識原則驾诈。開閉原則具有理想主義的色彩，它是面向對象設計的終極目標溶浴。設計模式正是通過實現(xiàn)這些原則來達到代碼復用乍迄、增強可維護性的目的。

這些原則并不是固定的士败，任何人都可以提出更好的原則

開閉原則（Open Closed Principle闯两，OCP）

此原則是由Bertrand Meyer提出的。原文是：“Software entities should be open for extension,but closed for modification”拱烁。

模塊應對擴展開放生蚁，而對修改關閉。模塊應盡量在不修改原來的代碼的情況下進行擴展戏自。

舉個例子邦投，假設現(xiàn)在有一個已經(jīng)開發(fā)完成的規(guī)模不小的軟件系統(tǒng)，有人提需求說我要再加一個功能擅笔，那么這時候去修改源代碼顯然是不明智的志衣，不僅違反了開閉原則屯援，而且那么多的代碼，工作量肯定也很大念脯。為了要實現(xiàn)這個需求狞洋，可以在原來的軟件系統(tǒng)中擴展出來一個功能，只需要編寫調試這個新功能模塊的代碼绿店，這就是開放擴展吉懊，關閉修改。

里氏代換原則（Liskov Substitution Principle假勿，LSP）

里氏代換原則是由Barbara Liskov提出的借嗽。可以描述為：子類繼承于父類转培，可以單獨調用恶导，如果調用的是父類的話，那么換成子類也完全可以運行浸须。從開閉原則可以看出惨寿，設計模式一個重要的部分是抽象化，里氏代換原則從另一個角度描述了抽象（父類）和具體（子類）之間的關系删窒。舉例裂垦，貓科動物可以完成捕獵這個動作，而老虎也可以完成捕獵易稠，在這個例子中缸废，貓科動物就是父類包蓝，老虎是繼承于貓科動物驶社、從貓科動物這個類擴展出來的子類。

可以說：里氏代換原則是繼承復用的一個基礎测萎。

依賴倒轉原則（Dependency Inversion Principle亡电，DIP）

若引用的對象有底層類型，那么就直接引用底層類型硅瞧。高層模塊不應該依賴于底層模塊

換句話說份乒，在程序里面調用的時候調用子類 ，子類依賴于父類腕唧，而父類不要依賴于子類或辖。也就是說，細節(jié)依賴于抽象枣接，可是抽象不應該依賴于細節(jié)颂暇。

依賴倒轉原則要求程序設計時應該考慮如何針對抽象編程。

以計算機系統(tǒng)為例但惶，依賴倒轉原則要求要針對接口編程耳鸯，而不是針對實現(xiàn)編程湿蛔。無論鍵盤鼠標、CPU县爬、內存等等這些硬件都是針對接口設計的阳啥，而如果要針對實現(xiàn)來設計，硬盤就要對應到某個特定（品牌/類型）的主板财喳，那么換硬盤時就需要把主板也換掉察迟。

接口隔離原則（Interface Segregation Principle，ISP）

每一個接口都是一個角色耳高，客戶端不應該依賴于它不需要的接口卷拘。

也就是：一個類對另一個類的依賴應該建立在最小的接口上。

意思是這樣的：應該把每一個接口都細化祝高，針對類去設計接口栗弟。如果一個接口里含有太多的方法，而對很多類來說里面的很多方法都是用不到的工闺，那么另外的類在實現(xiàn)這個接口時就要實現(xiàn)很多對它來說沒用的方法乍赫，浪費人力物力。對一個類來說陆蟆，實現(xiàn)很多它都能用得上的專用接口總比讓它實現(xiàn)一個臃腫而又有很多它用不上的方法要劃得來雷厂。

采用接口隔離原則對接口進行約束時，要注意以下幾點：

接口盡量小叠殷，但是要有限度改鲫。對接口進行細化可以提高程序設計靈活性是不掙的事實，但是如果過小林束，則會造成接口數(shù)量過多像棘，使設計復雜化。所以一定要適度壶冒。

為依賴接口的類定制服務缕题，只暴露給調用的類它需要的方法，它不需要的方法則隱藏起來胖腾。只有專注地為一個模塊提供定制服務烟零，才能建立最小的依賴關系。

提高內聚咸作，減少對外交互锨阿。使接口用最少的方法去完成最多的事情。

運用接口隔離原則记罚，一定要適度墅诡，接口設計的過大或過小都不好。

合成/聚合復用原則（Composite/Aggregate Reuse Principle毫胜，CARP）

了解這個原則應首先了解一下組合和聚合书斜。

組合（合成）和聚合都是對象關系的一種诬辈。聚合表示整體與部分的關系，表示“含有”荐吉，整體由部分組合而成焙糟，部分可以脫離整體作為一個獨立的個體存在。組合（合成）則是一種更強的聚合样屠，部分組成整體穿撮，而且不可分割，部分不能脫離整體而單獨存在痪欲。在組合（合成）關系中悦穿，部分和整體的生命周期一樣，組合的新的對象完全支配其組成部分业踢，包括他們的創(chuàng)建和銷毀栗柒。

復用原則的設計原則是：要盡量使用合成/聚合，盡量不要使用繼承

最小知識原則（Principle of Least Knowledge知举，PLK瞬沦，也叫迪米特法則）

一句話，一個對象應對其他對象有盡可能少的了解雇锡。

基本模式

創(chuàng)建型模式：單例模式逛钻、抽象工廠模式、建造者模式锰提、工廠模式曙痘、原型模式。

結構型模式：適配器模式立肘、橋接模式边坤、裝飾模式、組合模式赛不、外觀模式惩嘉、享元模式罢洲、代理模式踢故。

行為型模式：模版方法模式、命令模式惹苗、迭代器模式殿较、觀察者模式、中介者模式桩蓉、備忘錄模式淋纲、解釋器模式（Interpreter模式）、狀態(tài)模式院究、策略模式洽瞬、職責鏈模式(責任鏈模式)本涕、訪問者模式。

———————————————————

有不對的地方歡迎指出~~~

【本文由“大智慧聰明者”發(fā)布伙窃，2017年3月28日】