清潔程式碼：職責 — Janos Pasztor

責任
編寫程式碼時，必須以某種方式對其進行分段。組織單位可以是類或模組，具體取決於您的程式設計範例。一般的想法是，一段程式碼應該只處理一個責任。換句話說，做一件事，做得好。
但是責任是什麼？讓我們上一節課，例如，與學校的學生打交道。該課程將保留一個學生的資料。像這樣：

class Student {
  private string name;
  
  public void setName(string name) {
    this.name = name;
  }
  
  public string getName() {
    return this.name;
  }
}

Student joe = new Student();
joe.setName('Joe');
joe.save();

class MySQLStudentStorage {
  public Student getById(int id) {
    //...
  }
  
  public void store(Student Student) {
    //...
  }
}

class Student {
  //...
  
  public void save() {
    storage = new MySQLStudentStorage();
    storage.store(this);
  }
}

重構
讓我們看一個不同的例子。想象一下處理財務資料的系統。你知道，這是無聊的東西。您很可能擁有某種型別的資料庫，並且您必須向使用它的人員提供一些報告。這些報告將是Excel表格或某些描述的CSV檔案。
其中一份報告可能是每月收入/支出表。最初，您為財務人員構建了此表，以便他們可以根據您提供的資料執行他們的奇特報告軟體。有一天，令你驚訝的是，執行長走進你的房間，並要求你改變報告的一欄。她希望你很好地格式化數字，這樣她就更容易閱讀。當然，您希望讓您的執行長感到高興，因此您需要改變這一欄。
一切都很順利，直到本月末，財務人員再次嘗試使用該報告並將其匯入到他們的軟體中。一切都崩潰了。他們希望修復報告。我不知道你是否遇到了財務人員，但如果他們說他們希望他們的報告得到修復，那就意味著他們現在想要修復它。畢竟，這是本月底，他們需要提供自己的報告，如果因為你遲到，沒有人會詛咒。
你是做什麼？顯然，你還原了之前的改變。然後你給執行長寫了一封抱歉的信，下次你想要加薪時，你的記分卡肯定不會好看。或者您可以花時間重構程式碼以提供兩個單獨的報告而不是一個報告，並將其作為兩個功能出售給CEO。毋庸置疑，你必須花一些時間在上面，但擁有專門的CEO報告比在你的記錄上留下黑色標記要好得多。此外，下次執行長要求您更改某些內容時，您可以自由地這樣做，因為您確保一個模組只負責一件事，只有一個改變的理由。

結論
如您所見，本文中概述的單一責任原則非常符合商業業務利益。讓您編寫遵循此想法的程式碼符合公司的長遠利益。將變化壓縮到不屬於的類中將導致更大和更大的類，並導致巨大的維護難題。複雜的程式碼也意味著您需要進行的任何更改都需要數月而不是數天，因為您必須解決程式碼中有機發展的混亂。