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

本篇內(nèi)容主要講解“為什么類的職責(zé)要單一化”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實(shí)用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“為什么類的職責(zé)要單一化”吧!

單一職責(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)都會(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)前場景下，它確實(shí)是這樣。

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

這個(gè)時(shí)候我覺得你可以根據(jù)用戶信息的類型來進(jìn)行拆分，畢竟大而全的類其實(shí)并不好。怎么拆分呢?比如：可以根據(jù)用戶登錄場景拆分出用戶認(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ù)階段，對同一個(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ā)展的必然階段。

以上只是針對類這個(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ì)上是對業(yè)務(wù)的抽象，不同的業(yè)務(wù)應(yīng)該抽象成不同的接口，以保證每個(gè)類，每個(gè)模塊，每個(gè)系統(tǒng)都可以獨(dú)立擴(kuò)展。

到此，相信大家對“為什么類的職責(zé)要單一化”有了更深的了解，不妨來實(shí)際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！