SRP：?jiǎn)我宦氊?zé)原則

廣泛定義：任何一個(gè)軟件模塊都應(yīng)該有且只有一個(gè)被修改的原因。

現(xiàn)實(shí)生產(chǎn)中，軟件往往要滿足一些需求，必須要做出各種各樣的修改。而該系統(tǒng)的用戶或所有者就是該設(shè)計(jì)原則中指的“被修改的原因”。

定義Pro：任何一個(gè)軟件模塊都應(yīng)該只對(duì)某一類行為者負(fù)責(zé)。

例子

calculatePay、reportHours、save分別對(duì)應(yīng)了CFO、COO、CTO三方面，而這三個(gè)行為如果放在一個(gè)模塊里，實(shí)際上就是被耦合在了一起。

試想一下：calculatePay方法和reportHours方法使用同樣的邏輯來(lái)計(jì)算工時(shí)，一般程序員會(huì)把計(jì)算工時(shí)的方法實(shí)現(xiàn)為一個(gè)函數(shù)，如：regularHours

而接下來(lái)，CFO團(tuán)隊(duì)想要修改regularHours方法，其他團(tuán)隊(duì)不需要，這時(shí)就會(huì)出現(xiàn)問(wèn)題。因?yàn)槲覀儗⒉煌袨檎叩囊蕾噷懺诹艘黄稹?/p>

除了上面這個(gè)問(wèn)題，代碼合并也是因?yàn)橐粋€(gè)模塊。

解決方案

最核心的方案在于把相關(guān)的函數(shù)，劃分到不同的類里。

方案一：

最簡(jiǎn)單的就是將數(shù)據(jù)層與邏輯層分離，設(shè)計(jì)一個(gè)三個(gè)類共同使用的一個(gè)EmployeeData類。

缺點(diǎn)：

現(xiàn)在有三個(gè)類需要維護(hù)了。

方案二：

Facade模式

OCP: 開閉原則

良好的計(jì)算機(jī)軟件應(yīng)該易于擴(kuò)展，同時(shí)抗拒修改。

這其實(shí)也是我們研究軟件架構(gòu)的根本目的，如果對(duì)一個(gè)原始需求的小小延伸就要修改大部分的話，那這個(gè)軟件架構(gòu)無(wú)疑是非常失敗的。

以下為一個(gè)需求SRP后的流程

明確需求后，就可以修改源碼間的依賴關(guān)系了，保證修改一個(gè)操作不會(huì)影響其他的操作。

這個(gè)系統(tǒng)中很重要的一點(diǎn)就是所有模塊間的跨越都是單向的

LSP：里氏替換原則

如果對(duì)于每個(gè)類型是S的對(duì)象o1都存在一個(gè)類型為T 的對(duì)象o2，能使操作T類型的程序P在用o2替換o1時(shí)保持行為不變，我們就可以將S成為T的子類型。

例子

假設(shè)我們有一個(gè)License類

這就是符合LSP原則的

ISP：接口隔離原則

此原則來(lái)源于以下情況

有多個(gè)用戶想要使用OPS類，但是User1只要使用op1，User2使用op2，User3使用op3。這就導(dǎo)致，如果我們對(duì)op2做任何修改，User1即使不受影響，也要重新編譯和部署。

DIP：控制反轉(zhuǎn)原則

如果想要設(shè)計(jì)一個(gè)靈活的系統(tǒng)，那么在源碼的層面，依賴關(guān)系中應(yīng)該多引用抽象類型，而不是具體實(shí)現(xiàn)。

穩(wěn)定的抽象層

每次修改接口的時(shí)候，一定會(huì)去修改實(shí)現(xiàn)，而反過(guò)來(lái)卻很少要去修改抽象接口，所以我們可以認(rèn)為接口比實(shí)現(xiàn)更穩(wěn)定。因此：

• 應(yīng)該在代碼中多使用 抽象接口，盡量避免使用那些多變的具體實(shí)現(xiàn)類。（抽象工廠）

• 不要在具體實(shí)現(xiàn)類上創(chuàng)建衍生類。

• 不要覆蓋包含具體實(shí)現(xiàn)的函數(shù)。

• 應(yīng)該避免在代碼中寫入與任何具體實(shí)現(xiàn)相關(guān)的名字，或者是其他容易變動(dòng)事物的名字。

工廠模式