1.定義

　　就一個(gè)類而言，應(yīng)該僅有一個(gè)引起它變化的原因。

2.定義解讀

　　這是六大原則中最簡(jiǎn)單的一種，通俗點(diǎn)說(shuō)，就是不存在多個(gè)原因使得一個(gè)類發(fā)生變化，也就是一個(gè)類只負(fù)責(zé)一種職責(zé)的工作。

3.優(yōu)點(diǎn)

• 類的復(fù)雜度降低，一個(gè)類只負(fù)責(zé)一個(gè)功能，其邏輯要比負(fù)責(zé)多項(xiàng)功能簡(jiǎn)單的多；
• 類的可讀性增強(qiáng)，閱讀起來(lái)輕松；
• 可維護(hù)性強(qiáng)，一個(gè)易讀、簡(jiǎn)單的類自然也容易維護(hù)；
• 變更引起的風(fēng)險(xiǎn)降低，變更是必然的，如果單一職責(zé)原則遵守的好，當(dāng)修改一個(gè)功能時(shí)，可以顯著降低對(duì)其他功能的影響。

4.問(wèn)題提出

　　假設(shè)有一個(gè)類C，它負(fù)責(zé)兩個(gè)不同的職責(zé)：職責(zé)P1和P2。當(dāng)職責(zé)P1需求發(fā)生改變而需要修改類C時(shí)，有可能會(huì)導(dǎo)致原本運(yùn)行正常的職責(zé)P2功能發(fā)生故障。

5.解決方案

　　遵循單一職責(zé)原則。分別建立兩個(gè)類C1、C2，使C1完成職責(zé)P1，C2完成職責(zé)P2。這樣，當(dāng)修改類C1時(shí)，不會(huì)使職責(zé)P2發(fā)生故障風(fēng)險(xiǎn)；同理，當(dāng)修改C2時(shí)，也不會(huì)使職責(zé)P1發(fā)生故障風(fēng)險(xiǎn)。

　　說(shuō)到這里，大家會(huì)覺(jué)得這個(gè)原則太簡(jiǎn)單了。稍有經(jīng)驗(yàn)的程序員，即使沒(méi)有聽(tīng)說(shuō)過(guò)單一職責(zé)原則，在設(shè)計(jì)軟件時(shí)也會(huì)自覺(jué)的遵守這一重要原則。在實(shí)際的項(xiàng)目開(kāi)發(fā)中，誰(shuí)也不希望因?yàn)樾薷牧艘粋€(gè)功能導(dǎo)致其他的功能發(fā)生故障。而避免出現(xiàn)這一問(wèn)題的方法便是遵循單一職責(zé)原則。雖然單一職責(zé)原則如此簡(jiǎn)單，并且被認(rèn)為是常識(shí)，即便是經(jīng)驗(yàn)豐富的程序員寫(xiě)出的程序，也會(huì)有違背這一原則的代碼存在。為什么會(huì)出現(xiàn)這種現(xiàn)象呢？因?yàn)橛新氊?zé)擴(kuò)散。實(shí)際項(xiàng)目中，因?yàn)槟撤N原因，職責(zé)P被分化為粒度更細(xì)的職責(zé)P1和P2。

　　比如：類C只負(fù)責(zé)一個(gè)職責(zé)P，這樣設(shè)計(jì)是符合單一職責(zé)原則的。后來(lái)由于某種原因，也許是需求變更了，也許是客戶提出了新的功能，需要將職責(zé)P細(xì)分為粒度更細(xì)的職責(zé)P1，P2，這時(shí)如果要使程序遵循單一職責(zé)原則，需要將類C也分解為兩個(gè)類C1和C2，分別負(fù)責(zé)P1、P2兩個(gè)職責(zé)。但是在程序已經(jīng)寫(xiě)好的情況下，這樣做有時(shí)候需要花費(fèi)更多的工作量。在項(xiàng)目工期緊張的情況下，我們通常會(huì)簡(jiǎn)單的修改類C，用它來(lái)負(fù)責(zé)兩個(gè)職責(zé)，雖然這樣做有悖于單一職責(zé)原則。（這樣做的風(fēng)險(xiǎn)在于職責(zé)擴(kuò)散的不確定性，因?yàn)樵谖磥?lái)可能會(huì)擴(kuò)散出P1，P2，P3，P4……Pn。所以記住，在職責(zé)擴(kuò)散到我們無(wú)法控制的程度之前，立刻對(duì)代碼進(jìn)行重構(gòu)。）

6.示例

　　說(shuō)一個(gè)和我們密切相關(guān)的場(chǎng)景：員工的工資計(jì)算。剛開(kāi)始的時(shí)候，我們會(huì)新建一個(gè)員工類，在員工類里面有一個(gè)計(jì)算工資的方法，代碼如下所示：

class Employee {func calculateSalary(name: String){print("\(name)的工資是100");} }//調(diào)用 let employee = Employee(); employee.calculateSalary("小明"); //打印：小明的工資是100

　　產(chǎn)品上線后，問(wèn)題出來(lái)了，因?yàn)閱T工的崗位不同，工資的計(jì)算是不一樣的。修改時(shí)如果遵循單一職責(zé)原則，需要將Employee類細(xì)分為總監(jiān)類Director、經(jīng)理類Manager、普通員工類Staff，這三個(gè)類的實(shí)現(xiàn)代碼和Employee類一樣，只是方法calculateSalary有所不同。實(shí)際項(xiàng)目中，可以考慮將Employee定義為協(xié)議，Director、Manager、Staff實(shí)現(xiàn)該協(xié)議，這樣以后擴(kuò)展其他類型的職位增加相應(yīng)的類即可。

protocol Employee {func calculateSalary(name: String); }//總監(jiān) class Director: Employee {func calculateSalary(name: String){print("\(name)總監(jiān)的工資是10000");} }//經(jīng)理 class Manager: Employee {func calculateSalary(name: String){print("\(name)經(jīng)理的工資是1000");} }//普通員工 class Staff: Employee {func calculateSalary(name: String){print("\(name)員工的工資是100");} }//調(diào)用 let director = Director(); director.calculateSalary("張三"); //打印：張三總監(jiān)的工資是10000 let manager = Manager(); manager.calculateSalary("李四"); //打印：李四經(jīng)理的工資是1000 let staff = Staff(); staff.calculateSalary("王五"); //打印：王五員工的工資是100

　　上面的修改方式是在遵循單一職責(zé)原則下進(jìn)行的，從修改中，我們可以看到，這樣修改的工作量相對(duì)較大，需要新增不同的崗位類，還需要修改調(diào)用代碼。實(shí)際項(xiàng)目開(kāi)發(fā)中，我們可能會(huì)采取如下兩種方式：

　　【方式一】：直接修改Employee類里面的calculateSalary方法，在這里，我們需要對(duì)calculateSalary方法增加一個(gè)參數(shù)，以標(biāo)識(shí)員工的崗位。

　　修改后的calculateSalary方法如下所示：

enum EmployeeType {case Director;case Manager;case Staff; }class Employee {func calculateSalary(name: String, employeeType: EmployeeType){if .Director == employeeType{print("\(name)總監(jiān)的工資是10000");}else if .Manager == employeeType{print("\(name)經(jīng)理的工資是1000");}else if .Staff == employeeType{print("\(name)的工資是100");}} }//調(diào)用 let employee = Employee(); employee.calculateSalary("張三", employeeType: .Director); //打印：張三總監(jiān)的工資是10000 employee.calculateSalary("李四", employeeType: .Manager); //打印：李四經(jīng)理的工資是1000 employee.calculateSalary("王五", employeeType: .Staff); //打印：王五的工資是100

　　從上面可以看到，這種修改方式相對(duì)要簡(jiǎn)單的多，是直接在方法級(jí)別上違背了單一職責(zé)原則，雖然修改起來(lái)最簡(jiǎn)單，但隱患卻也是最大的。假設(shè)有一天需要將總監(jiān)分為財(cái)務(wù)總監(jiān)和研發(fā)總監(jiān)，則又需要修改Employee類的calculateSalary方法，而對(duì)原有代碼的修改會(huì)對(duì)已有功能帶來(lái)風(fēng)險(xiǎn)(可能會(huì)存在遺漏或者疏忽)。

　　【方式二】：在Employee類中新增不同崗位的工資計(jì)算方法，.h文件中新加的方法定義如下所示：

class Employee {func directorCalculateSalary(name: String){print("\(name)總監(jiān)的工資是10000");}func managerCalculateSalary(name: String){print("\(name)經(jīng)理的工資是1000");}func staffCalculateSalary(name: String){print("\(name)的工資是100");} }//調(diào)用 let employee = Employee(); employee.directorCalculateSalary("張三"); //打印：張三總監(jiān)的工資是10000 employee.managerCalculateSalary("李四"); //打印：李四經(jīng)理的工資是1000 employee.staffCalculateSalary("王五"); //打印：王五的工資是100

　　可以看到，方式二沒(méi)有改動(dòng)原來(lái)的方法，而是在類中新加了三個(gè)方法，這樣雖然也違背了單一職責(zé)原則，但在方法級(jí)別上卻是符合單一職責(zé)原則，因?yàn)樗](méi)有改變?cè)瓉?lái)方法的代碼。

7.示例總結(jié)

　　上面三種方式各有優(yōu)缺點(diǎn)，那么在實(shí)際編程中，該采用哪一種呢？這個(gè)問(wèn)題沒(méi)有標(biāo)準(zhǔn)答案，需要根據(jù)實(shí)際情況來(lái)確定。

?

轉(zhuǎn)載于:https://www.cnblogs.com/LeeGof/p/5704014.html

總結(jié)

以上是生活随笔為你收集整理的1.单一职责原则（Single Responsibility Principle）的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。