程序員過關(guān)斬將--領(lǐng)導(dǎo)說我的類的職責(zé)不單一
“為什么類的職責(zé)要單一化?
“類的職責(zé)單一化很容易嗎?
首先，我要提醒一下看到這篇文章的同學(xué)，我認(rèn)為保證類(一定是類嗎?)的單一職責(zé)并不容易
軟件開發(fā)過程中，自古就流傳著幾大規(guī)則，無論如何這里都要和大家闡述一遍
單一職責(zé)原則
一個(gè)類應(yīng)該只有一個(gè)發(fā)生變化的原因
開閉原則
軟件實(shí)體應(yīng)該是可擴(kuò)展，而不可修改的。也就是說，對(duì)擴(kuò)展是開放的，而對(duì)修改是封閉的。這個(gè)原則是諸多面向?qū)ο缶幊淘瓌t中最抽象、最難理解的一個(gè)。
里氏替換原則
所有引用基類的地方必須能透明地使用其子類的對(duì)象,換句話說，子類在任何引用基類的地方都可以替換成子類。
依賴倒置原則
這個(gè)原則說的詳細(xì)一點(diǎn)其實(shí)可以概括為兩點(diǎn)：
高層模塊不應(yīng)該直接依賴于底層模塊，應(yīng)該依賴于抽象
抽象不應(yīng)該依賴于具體實(shí)現(xiàn)，具體實(shí)現(xiàn)應(yīng)該依賴于抽象
接口隔離原則
程序不依賴于不使用的接口，換句話說，一個(gè)程序只依賴于它需要的接口。
單純從概念上講呢，單一職責(zé)原則可算是最簡單易懂的一種原則了，就像設(shè)計(jì)模式中的單例模式一樣無趣，是這樣嗎?
誰的職責(zé)
說實(shí)話，看過不少講解“職責(zé)單一”設(shè)計(jì)原則的文章，都是以類來闡述。其實(shí)我覺得不對(duì)，職責(zé)單一設(shè)計(jì)原則本質(zhì)上是軟件設(shè)計(jì)原則的一種思想，具有指導(dǎo)意義。至于誰的職責(zé)需要單一，是一個(gè)偽命題，不僅僅指面向?qū)ο缶幊讨械念悾到y(tǒng)的模塊，甚至于微服務(wù)在架構(gòu)設(shè)計(jì)中也應(yīng)該遵循此規(guī)則。
在面向?qū)ο笤O(shè)計(jì)的理解中，程序最基本的組成單位是類(class)，多個(gè)類組成模塊(module)，多個(gè)模塊組成服務(wù)(service)，多個(gè)服務(wù)組成系統(tǒng)(system)，一般的軟件系統(tǒng)都會(huì)存在以上幾個(gè)概念。
無論是類，還是模塊，還是服務(wù)，還是系統(tǒng)，我認(rèn)為設(shè)計(jì)的時(shí)候都要保證“單一職責(zé)”。
單一真的容易嗎
說到“單一”職責(zé)，每個(gè)人都有不同的看法
- class UserInfo
- {
- //用戶id
- public int UserId{get ;set ;}
- //用戶登錄賬號(hào)
- public string Account{get;set ;}
- //用戶登錄密碼
- public string Pwd{get ;set;}
- //用戶姓名
- public string Name{get ;set ;}
- }
以上是最常見的用戶信息實(shí)體，你認(rèn)為它職責(zé)單一嗎?說一說，我自己的看法：
站在用戶信息的角度來說，這個(gè)類代表的是用戶信息，它就是單一的，這也是大多數(shù)人的看法，有錯(cuò)嗎?其實(shí)沒錯(cuò)。因?yàn)樵诋?dāng)前場(chǎng)景下，它確實(shí)是這樣。
隨著業(yè)務(wù)的發(fā)展，用戶的信息字段會(huì)越來越多，比如：用戶的年齡，性別，學(xué)歷....等等。看著越來越大的UserInfo類，是否該拆分呢?
這個(gè)時(shí)候我覺得你可以根據(jù)用戶信息的類型來進(jìn)行拆分，畢竟大而全的類其實(shí)并不好。怎么拆分呢?比如：可以根據(jù)用戶登錄場(chǎng)景拆分出用戶認(rèn)證的類型
- class UserAuth
- {
- //用戶id
- public int UserId{get ;set ;}
- //用戶登錄賬號(hào)
- public string Account{get;set ;}
- //用戶登錄密碼
- public string Pwd{get ;set;}
- }
可以根據(jù)用戶信息在系統(tǒng)中的出現(xiàn)頻率和重要度拆分出用戶基本信息和用戶擴(kuò)展信息
- class UserBasicInfo
- {
- //用戶id
- public int UserId{get ;set ;}
- //用戶姓名
- public string Name{get ;set ;}
- //用戶手機(jī)號(hào)
- public string Phone{get ;set ;}
- //其他基本屬性
- }
- class UserExtendnfo
- {
- //用戶郵箱
- public string Email{get ;set ;}
- //用戶QQ號(hào)
- public string QQ{get ;set ;}
- //其他屬性
- }
當(dāng)然這里我只是舉個(gè)栗子，如果用戶的Email和手機(jī)號(hào)一樣常用，可以把Email屬性提到基本屬性中。
以上只是以用戶信息為例，根據(jù)不同的用途進(jìn)行拆分的一個(gè)栗子。在不同的業(yè)務(wù)背景下，不同的業(yè)務(wù)階段，對(duì)同一個(gè)類的拆分可能會(huì)有很大不同。有的時(shí)候，你所認(rèn)為的"正確“會(huì)隨著系統(tǒng)的發(fā)展慢慢變成”錯(cuò)誤“，當(dāng)然這種”錯(cuò)誤“并不可怕，畢竟系統(tǒng)的架構(gòu)都是慢慢迭代出來的。
總之呢，評(píng)價(jià)一個(gè)類是否一定滿足單一原則，并沒有一個(gè)統(tǒng)一標(biāo)準(zhǔn)和規(guī)范，在實(shí)際的開發(fā)中，也沒有必要進(jìn)行過度設(shè)計(jì)，在項(xiàng)目初級(jí)，完全可以是一個(gè)滿足業(yè)務(wù)需求的大而全的類，隨著業(yè)務(wù)的發(fā)展，你必然會(huì)經(jīng)歷拆分的過程，這也是軟件發(fā)展的必然階段。
以上只是針對(duì)類這個(gè)最基本的面向?qū)ο髥挝粊砹牧肆模仙侥K以及系統(tǒng)也是一樣的道理，微服務(wù)也是隨著軟件開發(fā)的不斷演進(jìn)而出現(xiàn)的，其實(shí)從職責(zé)上來看，微服務(wù)也是職責(zé)單一原則的產(chǎn)物，而這個(gè)這則單一更多的是傾向于業(yè)務(wù)單一性，并非功能單一性。
那職責(zé)拆分的越細(xì)越好嗎?我不這么認(rèn)為，當(dāng)一個(gè)類或者模塊甚至系統(tǒng)，被拆分過細(xì)的時(shí)候，就會(huì)面臨著維護(hù)的問題，拿微服務(wù)來說，當(dāng)微服務(wù)的數(shù)量過多，就會(huì)面臨著治理等一系列問題，這也是K8s要解決的問題之一。
拆分原則
說到底，雖然職責(zé)單一很難在主觀上給予準(zhǔn)確判斷，但是還是有一些通用規(guī)則可以借鑒，這里以類為例
- 高內(nèi)聚。系統(tǒng)在修改任一功能的時(shí)候，只需要修改一處地方，如果你需要修改多處才能滿足某個(gè)需求，很有可能你的職責(zé)劃分的不合理
- 屬性過多。當(dāng)一個(gè)類屬性過多的時(shí)候，可以考慮把這個(gè)類進(jìn)行職責(zé)的拆分。而至于多少個(gè)才算多呢?當(dāng)查找某個(gè)屬性令你頭疼的時(shí)候，說明已經(jīng)到了可以拆分的程度了(自己杜撰)
- 依賴過多。當(dāng)一個(gè)類型中依賴的資源過多的時(shí)候，可以進(jìn)行拆分
- 獨(dú)立變化。當(dāng)一個(gè)類的某些屬性被大量使用而且會(huì)經(jīng)常變化的時(shí)候，可以考慮把這些屬性進(jìn)行拆分成獨(dú)立的類。
說到職責(zé)單一，這里順便提一下接口的設(shè)計(jì)，接口的設(shè)計(jì)更要遵循職責(zé)單一的原則，接口本質(zhì)上是對(duì)業(yè)務(wù)的抽象，不同的業(yè)務(wù)應(yīng)該抽象成不同的接口，以保證每個(gè)類，每個(gè)模塊，每個(gè)系統(tǒng)都可以獨(dú)立擴(kuò)展。
寫在最后
沒有絕對(duì)好的方法可以讓所有人都認(rèn)為你的拆分是正確的“職責(zé)單一”，有的時(shí)候，怎么樣才能職責(zé)單一真是要靠“靈感”
本文轉(zhuǎn)載自微信公眾號(hào)「架構(gòu)師修行之路」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系架構(gòu)師修行之路公眾號(hào)。
