1箫措、開閉原則(OCP)
軟件實體應當對擴展開放，對修改關閉
簡單的說螺戳，就是軟件中包含的各種組件，應該在不修改現(xiàn)有代碼的基礎上猎唁，能夠擴展新功能。
開閉原則中的"開"顷蟆，是指對于組件功能的擴展是開放的诫隅，是允許對其進行功能擴展的；
開閉原則中的"閉"帐偎，是指對于代碼的修改是封閉的逐纬，即不應該修改原有的代碼。
問題由來：凡事的產(chǎn)生都有緣由削樊。我們來看看豁生，開閉原則的產(chǎn)生緣由兔毒。在軟件的生命周期內(nèi)，因為變化甸箱、升級和維護等原因需要對軟件原有代碼進行修改時育叁，可能會給舊代碼中引入錯誤，也可能會使我們不得不對整個功能進行重構(gòu)芍殖，并且需要原有代碼經(jīng)過重新測試豪嗽。這就對我們的整個系統(tǒng)的影響特別大，這也充分展現(xiàn)出了系統(tǒng)的耦合性如果太高围小，會大大的增加后期的擴展昵骤，維護树碱。為了解決這個問題肯适，故人們總結(jié)出了開閉原則。解決開閉原則的根本其實還是在解耦合成榜。所以框舔，我們面向?qū)ο蟮拈_發(fā)，我們最根本的任務就是解耦合赎婚。
解決方法：當軟件需要變化時刘绣，盡量通過擴展軟件實體的行為來實現(xiàn)變化，而不是通過修改已有的代碼來實現(xiàn)變化挣输。
小結(jié)：開閉原則具有理想主義的色彩纬凤，說的很抽象，它是面向?qū)ο笤O計的終極目標撩嚼。其他幾條原則停士，則可以看做是開閉原則的實現(xiàn)。我們要用抽象構(gòu)建框架完丽，用實現(xiàn)擴展細節(jié)恋技。
2、單一職責原則(SRP)
一個類逻族，只有一個引起它變化的原因蜻底。即：應該只有一個職責
每一個職責都是變化的一個軸線，如果一個類有一個以上的職責聘鳞，這些職責就耦合在了一起薄辅。這會導致脆弱的設計。當一個職責發(fā)生變化時抠璃，可能會影響其它的職責长搀。另外，多個職責耦合在一起鸡典，會影響復用性源请。例如：要實現(xiàn)邏輯和界面的分離。需要說明的一點是單一職責原則不只是面向?qū)ο缶幊趟枷胨赜械模灰悄K化的程序設計谁尸，都需要遵循這一重要原則舅踪。
問題由來：類T負責兩個不同的職責：職責P1，職責P2良蛮。當由于職責P1需求發(fā)生改變而需要修改類T時抽碌，有可能會導致原本運行正常的職責P2功能發(fā)生故障。
解決方法：分別建立兩個類T1决瞳、T2货徙，使T1完成職責P1功能，T2完成職責P2功能皮胡。這樣痴颊，當修改類T1時，不會使職責P2發(fā)生故障風險屡贺；同理蠢棱，當修改T2時，也不會使職責P1發(fā)生故障風險甩栈。
3泻仙、里式替換原則(LSP)
子類型必須能夠替換掉它們的父類型。注意這里的能夠兩字量没。有人也戲稱老鼠的兒子會打洞原則
問題由來：有一功能P1玉转，由類A完成。現(xiàn)需要將功能P1進行擴展殴蹄，擴展后的功能為P究抓，其中P由原有功能P1與新功能P2組成。新功能P由類A的子類B來完成饶套，則子類B在完成新功能P2的同時漩蟆，有可能會導致原有功能P1發(fā)生故障。
解決方法：類B繼承類A時妓蛮，除添加新的方法完成新增功能P2外怠李，盡量不要重寫父類A的方法，也盡量不要重載父類A的方法
小結(jié)：所有引用父類的地方必須能透明地使用其子類的對象蛤克。子類可以擴展父類的功能捺癞，但不能改變父類原有的功能，即：子類可以實現(xiàn)父類的抽象方法构挤，子類也中可以增加自己特有的方法髓介，但不能覆蓋父類的非抽象方法。當子類的方法重載父類的方法時筋现，方法的前置條件（即方法的形參）要比父類方法的輸入?yún)?shù)更寬松唐础。當子類的方法實現(xiàn)父類的抽象方法時箱歧，方法的后置條件（即方法的返回值）要比父類更嚴格。
4一膨、迪米特原則(Law Of Demeter)
迪米特法則又叫最少知道原則呀邢，即：一個對象應該對其他對象保持最少的了解。如果兩個類不必彼此直接通信豹绪，那么這兩個類就不應當發(fā)生直接的相互作用价淌。如果其中一個類需要調(diào)用另一個類的某一個方法的話，可以通過第三者轉(zhuǎn)發(fā)這個調(diào)用瞒津。簡單定義為只與直接的朋友通信蝉衣。
首先來解釋一下什么是直接的朋友：每個對象都會與其他對象有耦合關系，只要兩個對象之間有耦合關系巷蚪，我們就說這兩個對象之間是朋友關系病毡。耦合的方式很多，依賴钓辆、關聯(lián)剪验、組合肴焊、聚合等前联。其中，我們稱出現(xiàn)成員變量娶眷、方法參數(shù)似嗤、方法返回值中的類為直接的朋友，而出現(xiàn)在局部變量中的類則不是直接的朋友届宠。也就是說烁落，陌生的類最好不要作為局部變量的形式出現(xiàn)在類的內(nèi)部。
問題由來：類與類之間的關系越密切豌注，耦合度越大伤塌，當一個類發(fā)生改變時，對另一個類的影響也越大轧铁。
最早是在1987年由美國Northeastern University的Ian Holland提出每聪。通俗的來講，就是一個類對自己依賴的類知道的越少越好齿风。也就是說药薯，對于被依賴的類來說，無論邏輯多么復雜救斑，都盡量地的將邏輯封裝在類的內(nèi)部童本，對外除了提供的public方法，不對外泄漏任何信息脸候。迪米特法則還有一個更簡單的定義：只與直接的朋友通信穷娱。
解決方法：盡量降低類與類之間的耦合绑蔫。 自從我們接觸編程開始，就知道了軟件編程的總的原則：低耦合泵额，高內(nèi)聚晾匠。無論是面向過程編程還是面向?qū)ο缶幊蹋挥惺垢鱾€模塊之間的耦合盡量的低梯刚，才能提高代碼的復用率凉馆。
迪米特法則的初衷是降低類之間的耦合，由于每個類都減少了不必要的依賴亡资，因此的確可以降低耦合關系澜共。但是凡事都有度，雖然可以避免與非直接的類通信锥腻，但是要通信嗦董，必然會通過一個“中介”來發(fā)生聯(lián)系。故過分的使用迪米特原則瘦黑，會產(chǎn)生大量這樣的中介和傳遞類京革，導致系統(tǒng)復雜度變大。所以在采用迪米特法則時要反復權衡幸斥，既做到結(jié)構(gòu)清晰匹摇，又要高內(nèi)聚低耦合。
5甲葬、依賴倒置原則(DIP)
高層模塊不應該依賴低層模塊廊勃，二者都應該依賴其抽象；抽象不應該依賴細節(jié)经窖；細節(jié)應該依賴抽象坡垫。中心思想是面向接口編程
問題由來：類A直接依賴類B，假如要將類A改為依賴類C画侣，則必須通過修改類A的代碼來達成冰悠。這種場景下，類A一般是高層模塊配乱，負責復雜的業(yè)務邏輯溉卓；類B和類C是低層模塊，負責基本的原子操作宪卿；假如修改類A的诵，會給程序帶來不必要的風險。
解決方法：將類A修改為依賴接口I佑钾，類B和類C各自實現(xiàn)接口I西疤，類A通過接口I間接與類B或者類C發(fā)生聯(lián)系，則會大大降低修改類A的幾率休溶。
在實際編程中代赁，我們一般需要做到如下3點：
1）低層模塊盡量都要有抽象類或接口扰她，或者兩者都有。
2）變量的聲明類型盡量是抽象類或接口芭碍。
3）使用繼承時遵循里氏替換原則徒役。
采用依賴倒置原則尤其給多人合作開發(fā)帶來了極大的便利，參與協(xié)作開發(fā)的人越多窖壕、項目越龐大忧勿，采用依賴導致原則的意義就越重大。
小結(jié)：依賴倒置原則就是要我們面向接口編程瞻讽，理解了面向接口編程鸳吸，也就理解了依賴倒置。
6速勇、接口隔離原則(ISP)
客戶端不應該依賴它不需要的接口晌砾；一個類對另一個類的依賴應該建立在最小的接口上
問題由來：類A通過接口I依賴類B，類C通過接口I依賴類D烦磁，如果接口I對于類A和類B來說不是最小接口养匈，則類B和類D必須去實現(xiàn)他們不需要的方法
解決方法：1、 使用委托分離接口都伪。2呕乎、 使用多重繼承分離接口。3.將臃腫的接口I拆分為獨立的幾個接口院溺，類A和類C分別與他們需要的接口建立依賴關系楣嘁。也就是采用接口隔離原則磅轻。
舉例說明：下面我們來看張圖珍逸，一切就一目了然了。
image.png
這個圖的意思是：類A依賴接口I中的方法1聋溜、方法2谆膳、方法3，類B是對類A依賴的實現(xiàn)撮躁。類C依賴接口I中的方法1漱病、方法4、方法5把曼，類D是對類C依賴的實現(xiàn)杨帽。對于類B和類D來說，雖然他們都存在著用不到的方法（也就是圖中紅色字體標記的方法）嗤军，但由于實現(xiàn)了接口I注盈，所以也必須要實現(xiàn)這些用不到的方法
修改后：
image.png
如果接口過于臃腫，只要接口中出現(xiàn)的方法叙赚，不管對依賴于它的類有沒有用處老客，實現(xiàn)類中都必須去實現(xiàn)這些方法僚饭，這顯然不是好的設計。如果將這個設計修改為符合接口隔離原則胧砰，就必須對接口I進行拆分鳍鸵。在這里我們將原有的接口I拆分為三個接口
小結(jié)：我們在代碼編寫過程中，運用接口隔離原則尉间，一定要適度偿乖，接口設計的過大或過小都不好。對接口進行細化可以提高程序設計靈活性是不掙的事實哲嘲，但是如果過小汹想，則會造成接口數(shù)量過多，使設計復雜化撤蚊。所以一定要適度古掏。設計接口的時候，只有多花些時間去思考和籌劃侦啸，就能準確地實踐這一原則槽唾。
7、合成/聚合原則(CARP)
合成復用原則光涂，及盡量使用合成/聚合庞萍，盡量不要使用類繼承。換句話說忘闻，就是能用合成/聚合的地方钝计，絕不用繼承
為什么要盡量使用合成/聚合而不使用類繼承？
- 對象的繼承關系在編譯時就定義好了齐佳，所以無法在運行時改變從父類繼承的子類的實現(xiàn)
- 子類的實現(xiàn)和它的父類有非常緊密的依賴關系私恬，以至于父類實現(xiàn)中的任何變化必然會導致子類發(fā)生變化
- 當你復用子類的時候，如果繼承下來的實現(xiàn)不適合解決新的問題炼吴，則父類必須重寫或者被其它更適合的類所替換本鸣，這種依賴關系限制了靈活性，并最終限制了復用性硅蹦。
總結(jié)：這些原則在設計模式中體現(xiàn)的淋淋盡致荣德，設計模式就是實現(xiàn)了這些原則，從而達到了代碼復用童芹、增強了系統(tǒng)的擴展性涮瞻。所以設計模式被很多人奉為經(jīng)典。我們可以通過好好的研究設計模式假褪，來慢慢的體會這些設計原則署咽。
