2. 程式人生 > >編碼最佳實踐——單一職責原則

編碼最佳實踐——單一職責原則

阿新 • • 發佈：2018-11-05

SOLID是一組最佳編碼實踐的首字母縮寫

  • S 單一職責原則
  • O 開放與封閉原則
  • L Liskov（裡式）替換原則
  • I 介面分離原則
  • D 依賴注入原則

同時應用這些最佳實踐，可以提升程式碼適應變更的能力。但是凡事要有度，過度使用雖然可以讓程式碼有很高的自適應能力，但是會導致層次粒度過小而難以理解或使用，還會影響程式碼的可讀性。

mark

單一職責原則

單一職責原則（Single Responsibility principle）要求開發人員編寫的程式碼有且只有一個變更理由。如果一個類有多個變更理由，那麼它就具有多個職責。這個時候就要進行重構，將多職責類拆解為多個單職責類

。通過委託和抽象，包含多個變更理由的類應該把一個或多個職責委託給其他的單職責類。

之前看過一篇文章，講為什麼面向物件比面向過程更能適應業務變化？從其中也可以看出單一職責原則帶來的好處，職責明確，只需要修改區域性，不會對外部造成影響，影響可以控制在足以掌控的範圍內。

物件將需求用類一個個隔開，就像用儲物箱把東西一個個封裝起來一樣，需求變了，分幾種情況，最嚴重的是大變，那麼每個儲物箱都要開啟改，這種方法就不見得有好處；但是這種情況發生概率比較小，大部分需求變化都是侷限在一兩個儲物箱中，那麼我們只要開啟這兩個儲物箱修改就可以，不會影響其他儲物櫃了。

而面向過程是把所有東西都放在一個大儲物箱中，修改某個部分以後，會引起其他部分不穩定，一個BUG修復，引發新的無數BUG，最後程式設計師陷入焦頭爛額。

我們一段程式碼為例，通過重構的過程，體會一下單一職責原則的好處。

面向過程編碼

public class TradeRecord
{
    public int TradeAmount { get; set; }

    public decimal TradePrice { get; set; }
}
複製程式碼
public class TradeProcessor
{
    public void ProcessTrades(Stream stream)
    {
        var lines = new List<string>();

        using (var reader = new StreamReader(stream))
        {
            string line;
            while((line =reader.ReadLine()) != null)
            {
                lines.Add(line);
            }
        }

        var trades = new List<TradeRecord>();
        var lineCount = 1;
        foreach (var line in lines)
            {
                var fields = line.Split(new char[] { ',' });

                if(fields.Length != 3 )
                {
                    Console.WriteLine("WARN: Line {0} malformed. Only {1} fields found",lineCount, fields.Length);
                }

                int tradeAmount;
                if (!int.TryParse(fields[0], out tradeAmount))
                {
                    Console.WriteLine("WARN: Trade amount on line {0} not a valid integer :{1}",lineCount, fields[0]);
                }

                decimal tradePrice;
                if (!decimal.TryParse(fields[1], out tradePrice))
                {
                    Console.WriteLine("WARN: Trade Price on line {0} not a valid decimal :{1}", lineCount, fields[1]);
                }

                var tradeRecord = new TradeRecord
                {
                    TradeAmount = tradeAmount,
                    TradePrice = tradePrice
                };
                trades.Add(tradeRecord);
                lineCount++;
            }
        
        using (var connection = new SqlConnection("DataSource=(local);Initial Catalog=TradeDataBase;Integrated Security = True;"))
                {
                    connection.Open();
                    using (var transaction = connection.BeginTransaction())
                    {
                        foreach (var trade in trades)
                        {
                            var command = connection.CreateCommand();
                            command.Transaction = transaction;
                            command.CommandType = System.Data.CommandType.StoredProcedure;
                            command.CommandText = "insert_trade";

                            command.Parameters.AddWithValue("@tradeamount", trade.TradeAmount);
                            command.Parameters.AddWithValue("@tradeprice", trade.TradePrice);
                        }
                        transaction.Commit();
                    }
                    connection.Close();
                }

        Console.WriteLine("INFO: {0} trades processed",trades.Count);
    }
}
複製程式碼

上面的程式碼不僅僅是一個類擁有太多的職責，也是一個單一方法擁有太多的職責。仔細分析一下程式碼，原始的ProcessTrades方法程式碼可以分為三個部分：從流中讀取交易資料、將字串資料轉換為TradeRecord例項、將交易資料持久化到永久儲存。

單一職責原則可以表現在類和方法層面上。從方法的層面上，一個方法只能做一件事情；從類的層面上，一個類只能有一個職責。否則，就要對類和方法進行拆分重構。對於方法的拆分重構，目標是清晰度，能提升程式碼的可讀性，但是不能提升程式碼的自適應能力。要提升程式碼的自適應能力，就要做抽象，將每個職責劃分到不同的類中。

重構清晰度

上面我們分析過ProcessTrades方法程式碼可以分為三個部分，我們可以將每個部分提取為一個方法，將工作委託給這些方法，這樣ProcessTrades方法就變成了：

public void ProcessTrade(Stream stream)
{
    var lines = ReadTradeData(stream);
    var trades = ParseTrades(lines);
    StoreTrades(trades);
}
複製程式碼

提取的方法實現分別為：

/// <summary>
/// 從流中讀取交易資料
/// </summary>
/// <param name="stream"></param>
/// <returns></returns>
private IEnumerable<string> ReadTradeData(Stream stream)
{
    var tradeData = new List<string>();
    using (var reader = new StreamReader(stream))
    {
        string line;
        while ((line = reader.ReadLine()) != null)
        {
            tradeData.Add(line);
        }
    }
    return tradeData;
}
複製程式碼
/// <summary>
/// 將字串資料裝換位TradeRecord例項
/// </summary>
/// <param name="tradeData"></param>
/// <returns></returns>
private IEnumerable<TradeRecord> ParseTrades(IEnumerable<string> tradeData)
{
    var trades = new List<TradeRecord>();
    var lineCount = 1;
    foreach (var line in tradeData)
    {
        var fields = line.Split(new char[] { ',' });

        if(!ValidateTradeData(fields,lineCount))
        {
            continue;
        }

        var tradeRecord = MapTradeDataToTradeRecord(fields);
        trades.Add(tradeRecord);

        lineCount++;
    }
    return trades;
}
複製程式碼
/// <summary>
/// 交易資料持久化
/// </summary>
/// <param name="trades"></param>
private void StoreTrades(IEnumerable<TradeRecord> trades)
{
    using (var connection = new SqlConnection("DataSource=(local);Initial Catalog=TradeDataBase;Integrated Security = True;"))
    {
        connection.Open();
        using (var transaction = connection.BeginTransaction())
        {
            foreach (var trade in trades)
            {
                var command = connection.CreateCommand();
                command.Transaction = transaction;
                command.CommandType = System.Data.CommandType.StoredProcedure;
                command.CommandText = "insert_trade";

                command.Parameters.AddWithValue("@tradeamount", trade.TradeAmount);
                command.Parameters.AddWithValue("@tradeprice", trade.TradePrice);
            }
            transaction.Commit();
        }
        connection.Close();
    }

    Console.WriteLine("INFO: {0} trades processed", trades.Count());
}
複製程式碼

其中ParseTrades方法的實現比較特殊，負責的是將字串資料轉換為TradeRecord例項，包含資料的驗證和例項的建立。同理，將這些工作委託給了ValidateTradeData方法和MapTradeDataToTradeRecord方法。ValidateTradeData方法負責資料的驗證，只有合法的資料格式才能繼續組裝為TradeRecord例項，不合法的資料將會被記錄在日誌中。ValidateTradeData方法將記錄日誌的工作也委託給了LogMessage方法，具體實現如下：

/// <summary>
/// 驗證交易資料
/// </summary>
/// <param name="fields"></param>
/// <param name="currentLine"></param>
/// <returns></returns>
private bool ValidateTradeData(string[] fields,int currentLine)
{
    if (fields.Length != 3)
    {
        LogMessage("WARN: Line {0} malformed. Only {1} fields found", currentLine, fields.Length);
        return false;
    }

    int tradeAmount;
    if (!int.TryParse(fields[0], out tradeAmount))
    {
        LogMessage("WARN: Trade amount on line {0} not a valid integer :{1}", currentLine, fields[0]);
        return false;
    }

    decimal tradePrice;
    if (!decimal.TryParse(fields[1], out tradePrice))
    {
        LogMessage("WARN: Trade Price on line {0} not a valid decimal :{1}", currentLine, fields[1]);
        return false;
    }
    return true;
}
複製程式碼
/// <summary>
/// 組裝TradeRecord例項
/// </summary>
/// <param name="fields"></param>
/// <returns></returns>
private TradeRecord MapTradeDataToTradeRecord(string[] fields)
{
    int tradeAmount = int.Parse(fields[0]);
    decimal tradePrice = decimal.Parse(fields[1]);
    var tradeRecord = new TradeRecord
    {
        TradeAmount = tradeAmount,
        TradePrice = tradePrice
    };
    return tradeRecord;
}
複製程式碼
/// <summary>
/// 記錄日誌
/// </summary>
/// <param name="message"></param>
/// <param name="args"></param>
private void LogMessage(string message,params object[] args)
{
    Console.WriteLine(message,args);
}
複製程式碼

重構清晰度之後，程式碼的可讀性提高了，但是自適應能力並沒有提升多少。方法做到了只做一件事情，但是類的職責並不單一。還所以，要繼續重構抽象。

重構抽象

重構TradeProcessor抽象的第一步就是設計一個或一組介面來執行三個最高級別的任務：讀取資料、處理資料和儲存資料。

mark 

public class TradeProcessor
{
    private readonly ITradeDataProvider tradeDataProvider;
    private readonly ITradeParser tradeParser;
    private readonly ITradeStorage tradeStorage;

    public TradeProcessor(ITradeDataProvider tradeDataProvider,
        ITradeParser tradeParser,
        ITradeStorage tradeStorage)
    {
        this.tradeDataProvider = tradeDataProvider;
        this.tradeParser = tradeParser;
        this.tradeStorage = tradeStorage;
    }

    public void ProcessTrades()
    {
        var tradeData = tradeDataProvider.GetTradeData();
        var trades = tradeParser.Parse(tradeData);
        tradeStorage.Persist(trades);
    }
}
複製程式碼

作為客戶端的TradeProcessor類現在不清楚，當然也不應該清楚StreamTradeDataProvider類的實現細節，只能通過ITradeDataProvider介面的GetTradeData方法來獲取資料。TradeProcesso將不再包含任何交易流程處理的細節實現，取而代之的是整個流程的藍圖。

對於ITradeparser介面的實現Simpleradeparser類，還可以繼續提取更多的抽象，重構之後的UML圖如下。ITradeMapper負責資料格式的對映轉換，ITradeValidator負責資料的驗證。

mark 

public class TradeParser : ITradeParser
{
    private readonly ITradeValidator tradeValidator;
    private readonly ITradeMapper tradeMapper;
    public TradeParser(ITradeValidator tradeValidator, ITradeMapper tradeMapper)
    {
        this.tradeValidator = tradeValidator;
        this.tradeMapper = tradeMapper;
    }

    public IEnumerable<TradeRecord> Parse(IEnumerable<string> tradeData)
    {
        var trades = new List<TradeRecord>();
        var lineCount = 1;
        foreach (var line in tradeData)
        {
            var fields = line.Split(new char[] { ',' });

            if (!tradeValidator.Validate(fields, lineCount))
            {
                continue;
            }

            var tradeRecord = tradeMapper.MapTradeDataToTradeRecord(fields);
            trades.Add(tradeRecord);

            lineCount++;
        }
        return trades;
    }
}
複製程式碼

類似於上面將職責抽象為介面（及其實現）的過程是遞迴的。在檢視每個類時，你需要判斷它是否具備多重職責。如果是，提取抽象直到該類只具備單個職責。

重構抽象完成後的整個UML圖如下：

mark

需要注意的是，記錄日誌等一般需要依賴第三方程式集。對於第三方引用，應該通過包裝的方式轉換為第一方引用。這樣對於第三方的依賴可以被有效控制，在可預見的將來，替換第三方引用將會變得十分容易（只需要替換一處），否則專案中可能到處是對第三方引用的直接依賴。包裝一般是通過介面卡模式，此處使用的是物件介面卡模式。

mark

注意，示例中的程式碼實現對於依賴的抽象（介面），都是通過建構函式傳入的，也就是說物件依賴的具體實現在物件建立時就已經確定了。有兩種選擇，一是客戶端傳入手動建立的依賴物件（窮人版的依賴注入），二是使用IOC容器（依賴注入）。

需求變更

重構抽象後的新版本能在無需改變任何現有類的情況下實現以下的需求增強功能。我們可以模擬需求變更來體驗以下程式碼的自適應能力。

  • 當輸入資料的驗證規則變化時

    修改ITradeValidator介面的實現以反映最新的規則。

  • 當更改日誌記錄方式時，由視窗列印方式改為檔案記錄方式

    建立一個檔案記錄的FileLogger類實現檔案記錄日誌的功能，替換ILogger的具體實現。

  • 當資料庫發生了變化，例如使用文件資料庫替換關係型資料庫

    建立MongoTradeStorage類使用MongoDB儲存交易資料，替換ITradeStorage的具體實現。

最後

我們發現，符合單一職責原則的程式碼會由更多的小規模但目標更明確的類組成，然後通過介面抽象以及在執行時將無關功能的責任委託給相應的介面來達成目標的。更多的小規模但目標更明確的類通過自由組合的形式配合完成任務，每個類都可以看做是一個小零件，而介面就是生產這些零件的模具。當這個零件不再適合完成此任務時，就可以考慮替換掉這個零件，前提是替換前後的零件都是通過同一個模具生產出來的。

聰明的人從來不會把雞蛋放到同一個籃子裡，但是更聰明的人會考慮把這些籃子放到不同的車上。我們應該做更聰明的人，而不是每次系統出現問題時，在義大利麵條式的程式碼裡一遍又一遍的DeBug。

參考

《C#敏捷開發實踐》

作者： CoderFocus 微信公眾號：


相關推薦

編碼最佳實踐——單一職責原則

SOLID是一組最佳編碼實踐的首字母縮寫 S 單一職責原則 O 開放與封閉原則 L Liskov（裡式）替換原則 I 介面分離原則 D 依賴注入原則 同時應用這些最佳實踐，可以提升程式碼適應變更的能力。但是凡事要有度，過度使用雖然可以讓程式碼有很高的自適應能力，但是會導致層次粒度

編碼最佳實踐——開放封閉原則

開放封閉原則定義 開放與封閉原則有兩種不同的定義，分別是20世紀80年代最原始的定義和後期一個更現代的定義，後者對前者進行更加詳盡的闡述。 Meyer的定義 軟體實體應該允許擴充套件，但禁止修改 ​ ——《面向物件軟體構造》 Martin的定義 ”對於擴充套件是

編碼最佳實踐——Liskov替換原則

Liskov替換原則（Liskov Substitution Principle）是一組用於建立繼承層次結構的指導原則。按照Liskov替換原則建立的繼承層次結構中，客戶端程式碼能夠放心的使用它的任意類或子類而不擔心所期望的行為。 Liskov替換原則定義 如果S是T的子型別，那麼所有的T型別的物件都可以

編碼最佳實踐——介面分離原則

介面分離原則 在面向物件程式設計中，介面是一個非常重要的武器。介面所表達的是客戶端程式碼需求和需求具體實現之間的邊界。介面分離原則主張介面應該足夠小，大而全的契約（介面）是毫無意義的。 介面分離的原因 將大型介面分割為多個小型介面的原因有： ①需要單獨修飾介面 ②客戶端需要 ③架構需要 需要單獨修飾介面 我們

編碼最佳實踐——依賴注入原則

我們在這個系列的前四篇文章中分別介紹了SOLID原則中的前四個原則，今天來介紹最後一個原則——依賴注入原則。依賴注入（DI）是一個很簡單的概念，實現起來也很簡單。但是簡單卻掩蓋不了它的重要性，如果沒有依賴注入，前面的介紹的SOLID技術原則都不可能實際應用。 控制反轉(IoC) 人們在談論依賴注入的時候，經常

面向對象五大原則_1.單一職責原則&amp;2.裏氏替換原則

解決 一次 cti prot 輸入 名稱 enter wid col 單一職責原則:Single Responsibility Principle (SRP) 一個類。僅僅有一個引起它變化的原因。應該僅僅有一個職責。每個職責都是變化的一個軸線。假設一個類有一個以

設計模式學習筆記（二） 設計基本原則之【單一職責原則】

code 分享 開發者 實際應用 需要 ret ext file類 tor 單一職責原則（SRP： Single Responsibility Principle） 名詞解釋： 1） 職責：是指類變化的原因。 2） 職責擴散：就是因為某種原因，職責P被分化為粒度更細的職責P

《大話設計模式》——單一職責原則

有一個 導致 完成 如果能 原因 如果 分離 破壞 一個 單一職責原則(SRP)：就一個類而言，應該僅有一個能引起它變化的原因。 如果一個類承擔的職責過多，就等於把這些職責耦合在一起，一個職責的變化可能會削弱或抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當變化發

面向對象設計原則一：單一職責原則（SRP）

能夠 實現 update 之間 關註 linq 好處 相互 並且 單一職責原則（SRP） 定義：系統中的每一個類都應該只有一個職責。 好處：高內聚、低耦合。 解釋說明： 單一職責也就是說我們應該讓一個類或一個對象只做一件事情，每個類所要關註的就是自己要完成的

設計模式六大原則(一)：單一職責原則

控制 line 避免 多人 由來 pan 兩個類 思想 功能 單一職責定義： 不要存在多於一個導致類變更的原因，通俗的說，即一個類只負責一項職責。 問題由來： 類T負責兩個不同的職責：職責P1，職責P2。當由於職責P1需求發生改變而需要修改類T時，有可能會導致原

西遊記之設計模式原則——單一職責原則

void 可能 equals main person 方法 隱患 客戶端代碼 p s 單一職責原則 ——專心致誌只做一件事 1 package danyizhize; 2 3 class SunWuKong { 4 public void XiangM

2單一職責原則SRP

客戶 AS == password connect pre ons 不能 validate 一、什麽是單一職責原則 　　單一職責原則(Single Responsibility Principle )： 就一個類而言，應該僅有一個引起它變化的 原因。 二、多功能的

學習設計模式 - 六大基本原則之單一職責原則

enc more ref 組合 代碼 aso HERE ali 不可 　　設計模式總共有六大基本原則，統稱為SOLID （穩定）原則，分別是S-單一職責原則(Single Responsibility Principle)， O-開閉原則(Open closed Pri

[Python設計模式] 第3～5章 單一職責原則／開放-封閉原則／依賴倒轉原則

抽象類 內容 編寫 cat 過程 裏氏代換原則 數據庫連接 無需 維護 單一職責原則 就一個類而言，應該僅有一個引起它變化的原因。 如果一個類承擔的職責過多，就等於把這些職責耦合在一起，一個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當變

面向對象設計原則 單一職責原則（Single responsibility principle）

敏捷軟件開發 實現邏輯 導致 五個 單獨 無法 dot 單一職責原則 其它 單一職責原則（SRP：Single responsibility principle）又稱單一功能原則，面向對象五個基本原則（SOLID）之一。 它規定一個類應該只有一個發生變化的原因。 該原則

如何定義一個類——單一職責原則

就是 應該 系統 本質 獨立 ice 地方 tasks 很多 單一職責原則：就一個類而言，應該僅有一個引起他變化的原因。 1 一個老師類的例子 或者說在外部看來，一個類只應該能看到它的類的相關功能。如老師類只應該負責教授知識，備課，但是不應該負責開車。切合實際的說一個Ta

單一職責原則進階——多個地方的不同見解和解讀

高內聚 mooc its 下一個 次數 圖片 光貓 基於 對象 首先是定義 單一職責原則：一個類應該只有一個發生變化的原因英文名叫Single Responsibility Principle，以下簡稱為SRP 下面我們從三本著作中去解讀這個單一職責這三本著作分別是《

設計模式之六大設計原則之《一》魔性的單一職責原則

定義：單一職責原則，英文全稱Single Responsbility Property。怎樣的類設計才稱的上符合單一職責原則呢？一句話：應該有且僅有一個原因引起類的變更(There should never be more than one reason for a class to chang

第2章 面向物件的設計原則（SOLID）：1_單一職責原則（SRP）

1. 單一職責原則（Single Responsibility Principle，SRP） 1.1 單一職責的定義 （1）定義：一個類應該僅有一個引起它變化的原因。這裡變化的原因就是所說的“職責”。 （2）如果一個類有多個引起它變化的原因，也就意味著這個類有多個職責。即把多個職責耦合在

【學習筆記】慕課網—Java設計模式精講 第3章 軟體設計七大原則-3-4 單一職責原則

/** * 軟體設計七大原則-單一職責原則 學習筆記 * @author cnRicky * @date 2018.11.10 */ 單一職責原則 定義：不要存在多於一個導致類變更的原因 一個類只負責一個職責，如果分別有兩個職責，那就建立兩個類分別負責職責1和職責2 一個類/介面/方法只負