單一職責(zé)是降低耦合度的指導(dǎo)思想，適用于一個微服務(wù)，一個類型，一個方法。

微服務(wù)層：

微服務(wù)一般按業(yè)務(wù)的領(lǐng)域來進(jìn)行拆分：藥房微服務(wù)就是藥房的業(yè)務(wù)，護(hù)士站微服務(wù)就是護(hù)士站的業(yè)務(wù)，廣義上沒有什么問題，但對于一些共用業(yè)務(wù)，就犯難了，究竟放在那個微服務(wù)里？還是合并兩個微服務(wù)？其實這里就單一，把共用的抽離出來，不一定做成另一個微服務(wù)，可以統(tǒng)一做成類庫，供兩個微服務(wù)調(diào)用，如果業(yè)務(wù)有細(xì)微差別，可以通過設(shè)計模式來靈活解決異構(gòu)情況。

類型：

這里的類型，一般指復(fù)雜類型：如結(jié)構(gòu)體(struct)，接口(interface)，抽類(abstract class)，實例化類(class)，記錄(record)。這此類型內(nèi)部，重要的成員有屬性，方法，正是這些成員的規(guī)劃，是決定這些類型是否職責(zé)單一的重要指標(biāo)。

比如下面的用戶類型，這樣的定義是不沒有錯誤的，對于一些小型項目，這樣定義是最經(jīng)濟(jì)的。

/// <summary>/// 用戶/// </summary>class User{/// <summary>/// 用戶名 /// </summary>public string UserName { get; set; }/// <summary>/// 密碼/// </summary>public string Password { get; set; }/// <summary>/// 性名/// </summary>public string Name { get; set; }/// <summary>/// 性別 true男，false為女/// </summary>public bool Sex { get; set; }/// <summary>/// 職務(wù)/// </summary>public string Position { get; set; }/// <summary>/// 生日/// </summary>public DateTime Birthday { get; set; }}

如果從單一職責(zé)考慮，這個類可以分為三個類，如下：

/// <summary>/// 用戶/// </summary>class User{/// <summary>/// 用戶名 /// </summary>public string UserName { get; set; }/// <summary>/// 密碼/// </summary>public string Password { get; set; }}/// <summary>/// 人員職務(wù)/// </summary>class Position{/// <summary>/// 職務(wù)名稱/// </summary>public string PositionName { get; set; }}/// <summary>/// 人員/// </summary>class Person{/// <summary>/// 人員編號/// </summary>public string PersonNo { get; set; }/// <summary>/// 性名/// </summary>public string Name { get; set; }/// <summary>/// 性別 true男，false為女/// </summary>public bool Sex { get; set; }/// <summary>/// 年齡/// </summary>public int Age { get; set; }/// <summary>/// 用戶/// </summary>public User User { get; set; }/// <summary>/// 職務(wù)/// </summary>public Position[] Positions { get; set; }}

分開以后，雖然代碼增多了，但每個類的作用就單一了，用戶就是用戶，人員就是人員，職務(wù)分出來當(dāng)其擴(kuò)展時其他類型也不受影響。

方法：

越往下層，單一職責(zé)的把握越困難，特別是在寫一個方法的時候，單一的這個單位很模糊，怎么就算單一？

比如寫一個發(fā)送數(shù)據(jù)模塊，主要分部分：組織數(shù)據(jù)，發(fā)送數(shù)據(jù)，也就對應(yīng)兩個方法BuildData,SendData，可能在組織數(shù)據(jù)時發(fā)現(xiàn)，有些數(shù)據(jù)得作轉(zhuǎn)換，比如時間，類型等，這時可以在BuildData里作轉(zhuǎn)換，當(dāng)然也可以把轉(zhuǎn)換這部分抽離出來，組成一個TransformData，糾結(jié)的是，有時轉(zhuǎn)換數(shù)據(jù)只要一行代碼，如果按單一職責(zé)思想應(yīng)該分離出來，但看到分離的代碼覺得差強(qiáng)人意，有沒有一個標(biāo)準(zhǔn)呢？

這里我給出我自己的標(biāo)準(zhǔn)（僅代表自己的認(rèn)識）：

1、在糾結(jié)一個方法要不要拆開時，第一考慮是業(yè)務(wù)的單一性

2、有些業(yè)務(wù)之間當(dāng)前狀態(tài)統(tǒng)一的，要聯(lián)想下一步狀態(tài)，或下一階段，這種狀態(tài)是否持續(xù)(不要關(guān)心這個狀態(tài)在現(xiàn)實中什么時間到來)

3、多用一些經(jīng)典的設(shè)計模式來讓方法彼此隔離，互不干擾

總結(jié)

以上是生活随笔為你收集整理的单一职责在.NET中的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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