單一責任SRP設計舉例 - macerub

• generateInvoice：計算客戶必須支付的金額。
•  computeDiscount：為客戶返回％折扣。
•  save：將客戶儲存在資料庫中。
•  toString：將客戶作為字串返回，以便可以將其新增到報表中

這個類有多少職責？為了找出答案，我們應該問自己：

• 每種方法的受眾是誰？
• 誰可能要求更改這些方法的系統使用者（參與者）？

1. 業務專家或高管（定義業務規則）可以更改發票/折扣的計算方式。
2. 建築師（定義資料庫）可能會更改資料庫架構，從而影響“save”。
3. 職員（與客戶打交道）可能想要更改報告，從而影響“ toString”。

多種職責混合在一起的潛在問題：想一下，高管們改變了關於發票和折扣的政策。開發人員將不得不更改Customer類。如果他們引入了錯誤，那麼架構師和文員（不要求更改）可能會受到影響。
一個問題：想一下，職員和架構師都要求更改。一個開發人員可以被分配執行職員更改的任務。另一位開發人員可能會處理架構師的更改。兩者將在同一個模組上工作，互相踩腳趾。
 

總結：

• 單一責任就是僅為一名參與者提供服務的程式碼。
• 一個參與者代表著單一的變化源。
• 改變的原因之一就代表一項職責或責任。

你是整體思維還是分析思維？