編程中的六大設(shè)計(jì)原則?
1.單一職責(zé)原則 通俗地講就是一個(gè)類(lèi)只做一件事
? CALayer:動(dòng)畫(huà)和視圖的顯示凛忿。
? UIView:只負(fù)責(zé)事件傳遞画侣、事件響應(yīng)祥绞。
2.開(kāi)閉原則
對(duì)修改關(guān)閉，對(duì)擴(kuò)展開(kāi)放段誊。
要考慮到后續(xù)的擴(kuò)展性，而不是在原有的基礎(chǔ)上來(lái)回修改
3.接口隔離原則 使用多個(gè)專(zhuān)門(mén)的協(xié)議栈拖、而不是一個(gè)龐大臃腫的協(xié)議
? UITableviewDelegate ? UITableViewDataSource
4.依賴(lài)倒置原則
抽象不應(yīng)該依賴(lài)于具體實(shí)現(xiàn)连舍、具體實(shí)現(xiàn)可以依賴(lài)于抽象。
調(diào)用接口感覺(jué)不到內(nèi)部是如何操作的
5.里氏替換原則 父類(lèi)可以被子類(lèi)無(wú)縫替換涩哟，且原有的功能不受任何影響
例如 KVO
6.迪米特法則 一個(gè)對(duì)象應(yīng)當(dāng)對(duì)其他對(duì)象盡可能少的了解索赏，實(shí)現(xiàn)高聚合、低耦合

六大設(shè)計(jì)原則

單一職責(zé)原則
一個(gè)類(lèi)只承擔(dān)一個(gè)職責(zé)
開(kāi)閉原則
對(duì)擴(kuò)展開(kāi)發(fā)贴彼，對(duì)修改關(guān)閉
里氏替換原則
父類(lèi)可以被子類(lèi)無(wú)縫替換潜腻，且原有的功能不受影響。也就是說(shuō)器仗，最好不要重寫(xiě)融涣，而是新增。
接口隔離原則
使用多個(gè)專(zhuān)門(mén)的協(xié)議精钮，而不是一個(gè)龐大臃腫的協(xié)議
依賴(lài)倒置原則
抽象不應(yīng)該依賴(lài)于具體的實(shí)現(xiàn)威鹿，而實(shí)現(xiàn)依賴(lài)于抽象。
也就是說(shuō)轨香，調(diào)用接口感覺(jué)不到內(nèi)部是如何操作的忽你。
迪米特法則
一個(gè)對(duì)象應(yīng)該對(duì)其他對(duì)象盡可能少的了解，實(shí)現(xiàn)高內(nèi)聚臂容、低耦合

23種設(shè)計(jì)模式

創(chuàng)建型設(shè)計(jì)模式：主要用于創(chuàng)建對(duì)象
原型模式
單例模式
工廠方法模式
抽象工廠模式
建造者模式
結(jié)構(gòu)型設(shè)計(jì)模式：用于處理類(lèi)或?qū)ο蟮慕M合
適配器模式
橋接模式
組合模式
裝飾模式
外觀模式
享元模式
代理模式
行為型設(shè)計(jì)模式：用于描述類(lèi)或?qū)ο笤趺唇换ズ驮趺捶峙渎氊?zé)
責(zé)任鏈模式
命令模式
解釋器模式
迭代器模式
中介者模式
備忘錄模式
狀態(tài)模式
策略模式
模板方法模式
訪問(wèn)者模式
觀察者模式

1. 單一職責(zé)原則(SRP)

定義：就一個(gè)類(lèi)而言科雳，應(yīng)該僅有一個(gè)引起它變化的原因。
從這句定義我們很難理解它的含義策橘，通俗講就是我們不要讓一個(gè)類(lèi)承擔(dān)過(guò)多的職責(zé)炸渡。如果一個(gè)類(lèi)承擔(dān)的職責(zé)過(guò)多，就等于把這些職責(zé)耦合在一起丽已，一個(gè)職責(zé)的變化可能會(huì)削弱或者抑制這個(gè)類(lèi)完成其他職責(zé)的能力蚌堵。這種耦合會(huì)導(dǎo)致脆弱的設(shè)計(jì)，當(dāng)變化發(fā)生時(shí)沛婴，設(shè)計(jì)會(huì)遭受到破壞吼畏。
比如我經(jīng)常看到一些Android開(kāi)發(fā)在Activity中寫(xiě)B(tài)ean文件嘁灯，網(wǎng)絡(luò)數(shù)據(jù)處理泻蚊，如果有列表的話Adapter 也寫(xiě)在Activity中，問(wèn)他們?yōu)槭裁闯撕谜乙矝](méi)啥理由了丑婿，把他們拆分到其他類(lèi)豈不是更好找性雄，如果Activity過(guò)于臃腫行數(shù)過(guò)多没卸，顯然不是好事，如果我們要修改Bean文件秒旋，網(wǎng)絡(luò)處理和Adapter都需要上這個(gè)Activity來(lái)修改约计，就會(huì)導(dǎo)致引起這個(gè)Activity變化的原因太多，我們?cè)诎姹揪S護(hù)時(shí)也會(huì)比較頭疼迁筛。也就嚴(yán)重違背了定義“就一個(gè)類(lèi)而言煤蚌，應(yīng)該僅有一個(gè)引起它變化的原因”。
當(dāng)然如果想爭(zhēng)論的話细卧，這個(gè)模式是可以引起很多爭(zhēng)論的尉桩，但請(qǐng)記住一點(diǎn)，你寫(xiě)代碼不只是為了你也是為了其他人贪庙。

2. 開(kāi)放封閉原則(ASD)**

定義：類(lèi)蜘犁、模塊、函數(shù)等等等應(yīng)該是可以拓展的插勤，但是不可修改沽瘦。
開(kāi)放封閉有兩個(gè)含義革骨，一個(gè)是對(duì)于拓展是開(kāi)放的农尖，另一個(gè)是對(duì)于修改是封閉的。對(duì)于開(kāi)發(fā)來(lái)說(shuō)需求肯定是要變化的良哲，但是新需求一來(lái)盛卡，我們就要把類(lèi)重新改一遍這顯然是令人頭疼的，所以我們?cè)O(shè)計(jì)程序時(shí)面對(duì)需求的改變要盡可能的保證相對(duì)的穩(wěn)定筑凫，盡量用新代碼實(shí)現(xiàn)拓展來(lái)修改需求滑沧，而不是通過(guò)修改原有的代碼來(lái)實(shí)現(xiàn)。
假設(shè)我們要實(shí)現(xiàn)一個(gè)列表巍实，一開(kāi)始只有查詢(xún)的功能滓技，如果產(chǎn)品又要增加添加功能，過(guò)幾天又要增加刪除功能棚潦，大多數(shù)人的做法是寫(xiě)個(gè)方法然后通過(guò)傳入不同的值來(lái)控制方法來(lái)實(shí)現(xiàn)不同的功能令漂，但是如果又要新增功能我們還得修改我們的方法。用開(kāi)發(fā)封閉原則解決就是增加一個(gè)抽象的功能類(lèi)丸边，讓增加和刪除和查詢(xún)的作為這個(gè)抽象功能類(lèi)的子類(lèi)叠必，這樣如果我們?cè)偬砑庸δ埽銜?huì)發(fā)現(xiàn)我們不需要修改原有的類(lèi)妹窖，只需要添加一個(gè)功能類(lèi)的子類(lèi)實(shí)現(xiàn)功能類(lèi)的方法就可以了纬朝。

3.里氏替換原則(LSP)**

定義：所有引用基類(lèi)（父類(lèi)）的地方必須能透明地使用其子類(lèi)的對(duì)象
里氏代換原則告訴我們，在軟件中將一個(gè)基類(lèi)對(duì)象替換成它的子類(lèi)對(duì)象骄呼，程序?qū)⒉粫?huì)產(chǎn)生任何錯(cuò)誤和異常共苛，反過(guò)來(lái)則不成立判没，如果一個(gè)軟件實(shí)體使用的是一個(gè)子類(lèi)對(duì)象的話，那么它不一定能夠使用基類(lèi)對(duì)象隅茎。
里氏代換原則是實(shí)現(xiàn)開(kāi)閉原則的重要方式之一哆致，由于使用基類(lèi)對(duì)象的地方都可以使用子類(lèi)對(duì)象，因此在程序中盡量使用基類(lèi)類(lèi)型來(lái)對(duì)對(duì)象進(jìn)行定義患膛，而在運(yùn)行時(shí)再確定其子類(lèi)類(lèi)型摊阀，用子類(lèi)對(duì)象來(lái)替換父類(lèi)對(duì)象。
在使用里氏代換原則時(shí)需要注意如下幾個(gè)問(wèn)題：

• 子類(lèi)的所有方法必須在父類(lèi)中聲明踪蹬，或子類(lèi)必須實(shí)現(xiàn)父類(lèi)中聲明的所有方法胞此。根據(jù)里氏代換原則，為了保證系統(tǒng)的擴(kuò)展性跃捣，在程序中通常使用父類(lèi)來(lái)進(jìn)行定義漱牵，如果一個(gè)方法只存在子類(lèi)中，在父類(lèi)中不提供相應(yīng)的聲明疚漆，則無(wú)法在以父類(lèi)定義的對(duì)象中使用該方法酣胀。
• 我們?cè)谶\(yùn)用里氏代換原則時(shí)，盡量把父類(lèi)設(shè)計(jì)為抽象類(lèi)或者接口娶聘，讓子類(lèi)繼承父類(lèi)或?qū)崿F(xiàn)父接口闻镶，并實(shí)現(xiàn)在父類(lèi)中聲明的方法，運(yùn)行時(shí)丸升，子類(lèi)實(shí)例替換父類(lèi)實(shí)例铆农，我們可以很方便地?cái)U(kuò)展系統(tǒng)的功能，同時(shí)無(wú)須修改原有子類(lèi)的代碼狡耻，增加新的功能可以通過(guò)增加一個(gè)新的子類(lèi)來(lái)實(shí)現(xiàn)墩剖。里氏代換原則是開(kāi)閉原則的具體實(shí)現(xiàn)手段之一。
• Java語(yǔ)言中夷狰，在編譯階段岭皂，Java編譯器會(huì)檢查一個(gè)程序是否符合里氏代換原則，這是一個(gè)與實(shí)現(xiàn)無(wú)關(guān)的沼头、純語(yǔ)法意義上的檢查爷绘，但Java編譯器的檢查是有局限的。

4.依賴(lài)倒置原則(DIP)**

定義：高層模塊不應(yīng)該依賴(lài)低層模塊瘫证，兩個(gè)都應(yīng)該依賴(lài)于抽象揉阎。抽象不應(yīng)該依賴(lài)于細(xì)節(jié)，細(xì)節(jié)應(yīng)該依賴(lài)于抽象背捌。
在Java中毙籽，抽象就是指接口或者抽象類(lèi)，兩者都是不能直接被實(shí)例化的毡庆；細(xì)節(jié)就是實(shí)現(xiàn)類(lèi)坑赡，實(shí)現(xiàn)接口或者繼承抽象類(lèi)而產(chǎn)生的就是細(xì)節(jié)烙如，也就是可以加上一個(gè)關(guān)鍵字new產(chǎn)生的對(duì)象。高層模塊就是調(diào)用端毅否，低層模塊就是具體實(shí)現(xiàn)類(lèi)亚铁。
依賴(lài)倒置原則在Java中的表現(xiàn)就是：模塊間通過(guò)抽象發(fā)生，實(shí)現(xiàn)類(lèi)之間不發(fā)生直接依賴(lài)關(guān)系螟加，其依賴(lài)關(guān)系是通過(guò)接口或者抽象類(lèi)產(chǎn)生的徘溢。如果類(lèi)與類(lèi)直接依賴(lài)細(xì)節(jié)，那么就會(huì)直接耦合捆探，那么當(dāng)修改時(shí)然爆，就會(huì)同時(shí)修改依賴(lài)者代碼，這樣限制了可擴(kuò)展性黍图。

5.迪米特原則(LOD)**

定義：一個(gè)軟件實(shí)體應(yīng)當(dāng)盡可能少地與其他實(shí)體發(fā)生相互作用曾雕。
也稱(chēng)為最少知識(shí)原則。如果一個(gè)系統(tǒng)符合迪米特法則助被，那么當(dāng)其中某一個(gè)模塊發(fā)生修改時(shí)剖张，就會(huì)盡量少地影響其他模塊，擴(kuò)展會(huì)相對(duì)容易揩环，這是對(duì)軟件實(shí)體之間通信的限制搔弄，迪米特法則要求限制軟件實(shí)體之間通信的寬度和深度。迪米特法則可降低系統(tǒng)的耦合度检盼，使類(lèi)與類(lèi)之間保持松散的耦合關(guān)系肯污。
迪米特法則要求我們?cè)谠O(shè)計(jì)系統(tǒng)時(shí)翘单，應(yīng)該盡量減少對(duì)象之間的交互吨枉，如果兩個(gè)對(duì)象之間不必彼此直接通信，那么這兩個(gè)對(duì)象就不應(yīng)當(dāng)發(fā)生任何直接的相互作用哄芜，如果其中的一個(gè)對(duì)象需要調(diào)用另一個(gè)對(duì)象的某一個(gè)方法的話貌亭，可以通過(guò)第三者轉(zhuǎn)發(fā)這個(gè)調(diào)用。簡(jiǎn)言之认臊，就是通過(guò)引入一個(gè)合理的第三者來(lái)降低現(xiàn)有對(duì)象之間的耦合度圃庭。
在將迪米特法則運(yùn)用到系統(tǒng)設(shè)計(jì)中時(shí)，要注意下面的幾點(diǎn)：在類(lèi)的劃分上失晴，應(yīng)當(dāng)盡量創(chuàng)建松耦合的類(lèi)剧腻，類(lèi)之間的耦合度越低，就越有利于復(fù)用涂屁，一個(gè)處在松耦合中的類(lèi)一旦被修改书在，不會(huì)對(duì)關(guān)聯(lián)的類(lèi)造成太大波及；在類(lèi)的結(jié)構(gòu)設(shè)計(jì)上拆又，每一個(gè)類(lèi)都應(yīng)當(dāng)盡量降低其成員變量和成員函數(shù)的訪問(wèn)權(quán)限儒旬；在類(lèi)的設(shè)計(jì)上栏账，只要有可能，一個(gè)類(lèi)型應(yīng)當(dāng)設(shè)計(jì)成不變類(lèi)栈源；在對(duì)其他類(lèi)的引用上挡爵，一個(gè)對(duì)象對(duì)其他對(duì)象的引用應(yīng)當(dāng)降到最低。

6.接口隔離原則(ISP)**

定義：一個(gè)類(lèi)對(duì)另一個(gè)類(lèi)的依賴(lài)應(yīng)該建立在最小的接口上甚垦。
建立單一接口茶鹃，不要建立龐大臃腫的接口，盡量細(xì)化接口艰亮，接口中的方法盡量少前计。也就是說(shuō)，我們要為各個(gè)類(lèi)建立專(zhuān)用的接口垃杖，而不要試圖去建立一個(gè)很龐大的接口供所有依賴(lài)它的類(lèi)去調(diào)用男杈。
采用接口隔離原則對(duì)接口進(jìn)行約束時(shí)，要注意以下幾點(diǎn)：

• 接口盡量小调俘，但是要有限度伶棒。對(duì)接口進(jìn)行細(xì)化可以提高程序設(shè)計(jì)靈活性，但是如果過(guò)小彩库，則會(huì)造成接口數(shù)量過(guò)多肤无，使設(shè)計(jì)復(fù)雜化。所以一定要適度骇钦。
• 為依賴(lài)接口的類(lèi)定制服務(wù)宛渐，只暴露給調(diào)用的類(lèi)它需要的方法，它不需要的方法則隱藏起來(lái)眯搭。只有專(zhuān)注地為一個(gè)模塊提供定制服務(wù)窥翩，才能建立最小的依賴(lài)關(guān)系。
• 提高內(nèi)聚鳞仙，減少對(duì)外交互寇蚊。使接口用最少的方法去完成最多的事情。

這六個(gè)原則棍好，可以使我們?cè)趹?yīng)用的迭代維護(hù)中更加方便仗岸、輕松的應(yīng)對(duì)，讓我們的軟件更加靈活借笙。在后續(xù)的文章中我會(huì)給大家介紹其他的設(shè)計(jì)模式扒怖。