1. 何為單一職責(zé)原則
定義：就一個(gè)類而言，應(yīng)該僅有一個(gè)引起它變化的原因。
這是六大原則中最簡(jiǎn)單的一種，通俗點(diǎn)講，就是不存在多個(gè)原因使得一個(gè)類發(fā)生變化，一個(gè)類只負(fù)責(zé)一種職責(zé)。
優(yōu)點(diǎn)：
類的復(fù)雜度降低，一個(gè)類只負(fù)責(zé)一個(gè)功能，其邏輯要比負(fù)責(zé)多項(xiàng)功能簡(jiǎn)單的多；
類的可讀性增強(qiáng)，閱讀起來輕松；
可維護(hù)性強(qiáng)，一個(gè)易讀、簡(jiǎn)單的類自然也容易維護(hù)；
變更引起的風(fēng)險(xiǎn)降低，變更時(shí)必然的，如果單一職責(zé)原則遵守的好，當(dāng)修改一個(gè)功能時(shí)，可以顯著降低對(duì)其功能的影響；
2. 情景設(shè)置
假設(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ā)生故障。
解決方案
遵循單一職責(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)。
說到這里，大家會(huì)覺得這個(gè)原則太簡(jiǎn)單了。稍有經(jīng)驗(yàn)的程序員，即使沒有聽說過單一職責(zé)原則，在設(shè)計(jì)軟件時(shí)也會(huì)自覺的遵守這一重要原則。在實(shí)際的項(xiàng)目開發(fā)中，誰也不希望因?yàn)樾薷牧艘粋€(gè)功能導(dǎo)致其他的功能發(fā)生故障。而避免出現(xiàn)這一問題的方法便是遵循單一職責(zé)原則。雖然單一職責(zé)原則如此簡(jiǎn)單，并且被認(rèn)為是常識(shí)，即便是經(jīng)驗(yàn)豐富的程序員寫出的程序，也會(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é)原則的。后來由于某種原因，也許是需求變更了，也許是客戶提出了新的功能，需要將職責(zé)P細(xì)分為粒度更細(xì)的職責(zé)P1，P2，這時(shí)如果要使程序遵循單一職責(zé)原則，需要將類C也分解為兩個(gè)類C1和C2，分別負(fù)責(zé)P1、P2兩個(gè)職責(zé)。但是在程序已經(jīng)寫好的情況下，這樣做有時(shí)候需要花費(fèi)更多的工作量。在項(xiàng)目工期緊張的情況下，我們通常會(huì)簡(jiǎn)單的修改類C，用它來負(fù)責(zé)兩個(gè)職責(zé)，雖然這樣做有悖于單一職責(zé)原則。（這樣做的風(fēng)險(xiǎn)在于職責(zé)擴(kuò)散的不確定性，因?yàn)樵谖磥砜赡軙?huì)擴(kuò)散出P1，P2，P3，P4……Pn。所以記住，在職責(zé)擴(kuò)散到我們無法控制的程度之前，立刻對(duì)代碼進(jìn)行重構(gòu)。）
3. 代碼示例
說一個(gè)和我們密切相關(guān)的場(chǎng)景：?jiǎn)T工的工資計(jì)算。剛開始的時(shí)候，我們會(huì)新建一個(gè)員工類，在員工類里面有一個(gè)計(jì)算工資的方法，代碼如下所示：
（1）Employee
@interface Employee : NSObject
// 計(jì)算工資
- (void)calculateSalary:(NSString *)name;
@end
@implementation Employee
- (void)calculateSalary:(NSString *)name
{
NSLog(@"%@的工資是100",name);
}
@end
（2）調(diào)用代碼
Employee *employee = [[Employee alloc] init];
[employee calculateSalary:@"張三"];
[employee calculateSalary:@"李四"];
產(chǎn)品上線后，問題出來了，因?yàn)閱T工的崗位不同，工資的計(jì)算是不一樣的。修改時(shí)如果遵循單一職責(zé)原則，需要將Employee類細(xì)分為總監(jiān)類Director、經(jīng)理類Manager、普通員工類Staff，這三個(gè)類的實(shí)現(xiàn)代碼和Employee類一樣，只是方法calculateSalary有所不同。
上面的修改方式是在遵循單一職責(zé)原則下進(jìn)行的，從修改中，我們可以看到，這樣修改的工作量相對(duì)較大，需要新增不同的崗位類，還需要修改調(diào)用代碼。實(shí)際項(xiàng)目開發(fā)中，我們可能會(huì)采取如下兩種方式：
【方式一】：直接修改Employee類里面的calculateSalary方法，在這里，我們需要對(duì)calculateSalary方法增加一個(gè)參數(shù)，以標(biāo)識(shí)員工的崗位。
修改后的calculateSalary方法如下所示：
// 計(jì)算工資,增加員工崗位的標(biāo)識(shí)(Director:總監(jiān);Manager:經(jīng)理;Staff:普通員工)
- (void)calculateSalary:(NSString *)name flag:(NSString *)flag
{
if ([flag isEqualToString:@"Director"])
{
NSLog(@"%@總監(jiān)的工資是10000",name);
}
else if ([flag isEqualToString:@"Manager"])
{
NSLog(@"%@經(jīng)理的工資是1000",name);
}
else if ([flag isEqualToString:@"Staff"])
{
NSLog(@"%@員工的工資是100",name);
}
}
調(diào)用代碼如下：
Employee *employee = [[Employee alloc] init];
[employee calculateSalary:@"張三" flag:@"Director"];
[employee calculateSalary:@"李四" flag:@"Manager"];
[employee calculateSalary:@"王五" flag:@"Staff"];
從上面可以看到，這種修改方式相對(duì)要簡(jiǎn)單的多，是直接在代碼級(jí)別上違背了單一職責(zé)原則，雖然修改起來最簡(jiǎn)單，但隱患卻也是最大的。假設(shè)有一天需要將總監(jiān)分為財(cái)務(wù)總監(jiān)和研發(fā)總監(jiān)，則又需要修改Employee類的calculateSalary方法，而對(duì)原有代碼的修改會(huì)對(duì)已有功能帶來風(fēng)險(xiǎn)(可能會(huì)存在遺漏或者疏忽)。
【方式二】：在Employee類中新增不同崗位的工資計(jì)算方法，.h文件中新加的方法定義如下所示：
// 總監(jiān)工資計(jì)算
- (void)directorCalculateSalary:(NSString *)name;
// 經(jīng)理工資計(jì)算
- (void)managerCalculateSalary:(NSString *)name;
// 普通員工工資計(jì)算
- (void)staffCalculateSalary:(NSString *)name;
調(diào)用代碼如下：
Employee *employee = [[Employee alloc] init];
[employee directorCalculateSalary:@"張三"];
[employee managerCalculateSalary:@"李四"];
[employee staffCalculateSalary:@"王五"];
可以看到，方式二沒有改動(dòng)原來的方法，而是在類中新加了三個(gè)方法，這樣雖然也違背了單一職責(zé)原則，但在方法級(jí)別上卻是符合單一職責(zé)原則，因?yàn)樗]有改變?cè)瓉矸椒ǖ拇a。
上面三種方式各有優(yōu)缺點(diǎn)，那么在實(shí)際編程中，該采用哪一種呢？這個(gè)問題沒有標(biāo)準(zhǔn)答案，需要根據(jù)實(shí)際情況來確定。
