[[384751]]

“為什么類的職責(zé)要單一化?

“類的職責(zé)單一化很容易嗎?

首先，我要提醒一下看到這篇文章的同學(xué)，我認(rèn)為保證類(一定是類嗎?)的單一職責(zé)并不容易

軟件開發(fā)過程中，自古就流傳著幾大規(guī)則，無論如何這里都要和大家闡述一遍

單一職責(zé)原則

一個(gè)類應(yīng)該只有一個(gè)發(fā)生變化的原因

開閉原則

軟件實(shí)體應(yīng)該是可擴(kuò)展，而不可修改的。也就是說，對擴(kuò)展是開放的，而對修改是封閉的。這個(gè)原則是諸多面向?qū)ο缶幊淘瓌t中最抽象、最難理解的一個(gè)。

里氏替換原則

所有引用基類的地方必須能透明地使用其子類的對象,換句話說，子類在任何引用基類的地方都可以替換成子類。

依賴倒置原則

這個(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í)我覺得不對，職責(zé)單一設(shè)計(jì)原則本質(zhì)上是軟件設(shè)計(jì)原則的一種思想，具有指導(dǎo)意義。至于誰的職責(zé)需要單一，是一個(gè)偽命題，不僅僅指面向?qū)ο缶幊讨械念?，系統(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)都會存在以上幾個(gè)概念。

無論是類，還是模塊，還是服務(wù)，還是系統(tǒng)，我認(rèn)為設(shè)計(jì)的時(shí)候都要保證“單一職責(zé)”。

單一真的容易嗎

說到“單一”職責(zé)，每個(gè)人都有不同的看法

class UserInfo 
{ 
    //用戶id 
    public int UserId{get ;set ;} 
    //用戶登錄賬號 
    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)前場景下，它確實(shí)是這樣。

隨著業(yè)務(wù)的發(fā)展，用戶的信息字段會越來越多，比如：用戶的年齡，性別，學(xué)歷....等等?？粗絹碓酱蟮腢serInfo類，是否該拆分呢?

這個(gè)時(shí)候我覺得你可以根據(jù)用戶信息的類型來進(jìn)行拆分，畢竟大而全的類其實(shí)并不好。怎么拆分呢?比如：可以根據(jù)用戶登錄場景拆分出用戶認(rèn)證的類型

class UserAuth 
{ 
     //用戶id 
    public int UserId{get ;set ;} 
    //用戶登錄賬號 
    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ī)號 
    public string Phone{get ;set ;} 
 
    //其他基本屬性 
} 

class UserExtendnfo 
{     
     //用戶郵箱 
    public string Email{get ;set ;} 
    //用戶QQ號 
    public string QQ{get ;set ;} 
 
    //其他屬性 
} 

當(dāng)然這里我只是舉個(gè)栗子，如果用戶的Email和手機(jī)號一樣常用，可以把Email屬性提到基本屬性中。

以上只是以用戶信息為例，根據(jù)不同的用途進(jìn)行拆分的一個(gè)栗子。在不同的業(yè)務(wù)背景下，不同的業(yè)務(wù)階段，對同一個(gè)類的拆分可能會有很大不同。有的時(shí)候，你所認(rèn)為的"正確“會隨著系統(tǒng)的發(fā)展慢慢變成”錯(cuò)誤“，當(dāng)然這種”錯(cuò)誤“并不可怕，畢竟系統(tǒng)的架構(gòu)都是慢慢迭代出來的。

總之呢，評價(jià)一個(gè)類是否一定滿足單一原則，并沒有一個(gè)統(tǒng)一標(biāo)準(zhǔn)和規(guī)范，在實(shí)際的開發(fā)中，也沒有必要進(jìn)行過度設(shè)計(jì)，在項(xiàng)目初級，完全可以是一個(gè)滿足業(yè)務(wù)需求的大而全的類，隨著業(yè)務(wù)的發(fā)展，你必然會經(jīng)歷拆分的過程，這也是軟件發(fā)展的必然階段。

以上只是針對類這個(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í)候，就會面臨著維護(hù)的問題，拿微服務(wù)來說，當(dāng)微服務(wù)的數(shù)量過多，就會面臨著治理等一系列問題，這也是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è)類的某些屬性被大量使用而且會經(jīng)常變化的時(shí)候，可以考慮把這些屬性進(jìn)行拆分成獨(dú)立的類。

說到職責(zé)單一，這里順便提一下接口的設(shè)計(jì)，接口的設(shè)計(jì)更要遵循職責(zé)單一的原則，接口本質(zhì)上是對業(yè)務(wù)的抽象，不同的業(yè)務(wù)應(yīng)該抽象成不同的接口，以保證每個(gè)類，每個(gè)模塊，每個(gè)系統(tǒng)都可以獨(dú)立擴(kuò)展。

寫在最后

沒有絕對好的方法可以讓所有人都認(rèn)為你的拆分是正確的“職責(zé)單一”，有的時(shí)候，怎么樣才能職責(zé)單一真是要靠“靈感”

本文轉(zhuǎn)載自微信公眾號「架構(gòu)師修行之路」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系架構(gòu)師修行之路公眾號。