石頭自清潔掃拖機器人G10S評測：多年黑科技集大成之作 懶人終極福音
科技圈經常能看到一個詞叫“縫合怪”，用來形容那些把好多功能或者外觀結合在一起的產品，通常這樣的詞是貶義詞，但如果真的是產品縫合的好、縫合的實用的話，那它就成了中性詞，今
在日常開發工作中，經常會聽到有經驗的技術念叨xxx需要注意單一職責，那么，什么是單一職責？如何做才能保證職責單一？這篇文章幫你分析透。
關于單一職責，看過很多版本的解釋，這里歸納最常見的三個版本：
哪個版本的解釋比較合理呢？
單一職責原則，英文是：Single responsibility principle（SRP），是 Robert C. Martin提出的 SOLID原則中的一種，所以，我們先看看 作者對單一職責原則的描述，這里摘取了作者關于單一職責的原文：
The Single Responsibility Principle (SRP) states thateach software module should have one and only one reason to change.原文翻譯為：單一職責原則指出，任何一個軟件模塊都應該有一個且只有一個修改的理由。
定義看起來很嚴謹，但似乎和現實是相沖突的，因為軟件設計本身就是一門關注長期變化的學問，變化是軟件中最常見不過的問題，在現實環境中，軟件系統為了滿足用戶和所有者的要求，勢必會作出各種修改，而系統的用戶或者所有者就是該設計原則所指的"被修改的原因"。
于是乎，作者又重新把單一職責描述為：
The single responsibility principle states that every moduleor class should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by the class.原文翻譯為：單一職責原則指出，每個模塊或類應該只負責軟件所提供功能的一部分，并且這個職責應該完全被該類封裝。
在這個定義中，每個模塊或者類只負責軟件的一部分功能，那這一部分是多少呢？這部分功能是否可以包含不同類型的行為呢？比如，電商中的訂單和物流都可以叫做電商的一部分功能，但是他們在業務意義上顯然是不同的領域，因此，該定義缺乏了定性。
于是乎，作者再次修改了單一職責的定義：
Each module should only be responsible to one actor.原文翻譯為：任何一個軟件模塊都應該只對某一類行為者負責
這個定義，只要是能歸結成一類的行為，都可以屬于某個模塊的功能，這樣定義看起來更符合現實業務的語意。
在上述單一職責幾個定義中都提到了軟件模塊，那么，軟件模塊到底是什么呢？
軟件模塊（Software Module）是指軟件系統中的一個獨立單元，它包含一組相關的功能和數據，這些模塊是通過封裝數據和功能來實現的，以便實現更高的代碼復用性、可維護性和可擴展性。通常具有以下特點：
為了更好地說明軟件模塊，這里以一個電商系統為例，它可能包含以下幾個模塊：
(1) 用戶管理模塊：
(2) 訂單管理模塊：
(3) 支付處理模塊：
(4) 庫存管理模塊：
為了更好的說明任何一個軟件模塊都應該只對某一類行為者負責這個定義，下面我們通過2個 Java反例來進行演示。
假設有一個 Employee員工類并且包含以下 3個方法：
public class Employee { // calculatePay() 實現計算員工薪酬 public Money calculatePay(); // save() 將Employee對象管理的數據存儲到企業數據庫中 public void save(); // postEvent() 用于促銷活動發布 public void postEvent();}剛看上去，這個類設計得還挺符合實際業務，員工有計算薪酬、保存數據、發布促銷等行為，但是這 3個方法對應三類不同的行為者，計算薪酬屬于財務的行為，保存數據屬于數據管理員的行為，發布促銷屬于銷售的行為。
因此，Employee類將三類行為耦合在一起，違反了單一職責原則。假如一個普通員工不小心調用了calculatePay()方法，把每個員工的薪酬計算成了實際工資的2位，那可想而知這是一個災難性的問題。
如果增加新需求，要求員工能夠導出報表，因此，需要在 Employee類中增加了一個新的方法，代碼如下：
// 導出報表void exportReport();接著需求又一個一個增加，Employee類就得一次一次的變動，這會導致什么結果呢？
一方面，Employee類會不斷地膨脹；另一方面，可能業務需求完全不同，卻始終需要在同一個 Employee類上改動，合理嗎？
聯想一下你的日常開發，是否也有這樣的設計？把很多不同的行為都耦合到同一個類中，然后隨著業務的增加，該類急劇膨脹，最后無法維護。
該如何解決這種問題呢？
解決這個問題的方法有很多，特定的行為只能由特定的行為者來操作，因此，需要把 Employee類拆解成 3種行為者（財務、數據管理員、銷售），Employee類拆分之后的代碼如下：
// 財務行為public class FinanceStaff { public Money calculatePay();}// 數據管理員行為public class TechnicalStaff { public void save();}// 銷售行為public class OperatorStaff { public String postEvent();}假設需要開發一個電商系統，其中有一個 Order訂單類，負責處理訂單的創建、訂單的支付以及訂單的通知，代碼如下：
public class Order { public void createOrder() { // 訂單創建邏輯 } public void processPayment() { // 支付處理邏輯 } public void sendNotification() { // 發送通知邏輯 }}在上述代碼中，Order類同時承擔了訂單創建、支付處理和通知發送的職責，違反了單一職責原則，因為一個類有多個引起變化的原因。
為了遵循SRP，我們需要將不同的職責分離到不同的類中，因此可以創建三個類：Order類負責訂單創建，PaymentProcessor類負責支付處理，NotificationService類負責通知發送，每個類都只承擔一個職責，從而遵循了單一職責原則。代碼如下：
public class Order { public void createOrder() { // 訂單創建邏輯 }}public class PaymentProcessor { public void processPayment(Order order) { // 支付處理邏輯 }}public class NotificationService { public void sendNotification(Order order) { // 發送通知邏輯 }}上面2個示例代碼的拆分都遵從了原則：因相同原因而發生變化的事物聚集在一起，因不同原因而改變的事物分開。這就是單一職責的真正體現，也是定義內聚和耦合的一種方式。
從作者 Robert C. Martin對單一職責的 3次定義變更，我們可以看出：
回歸到實際的工作中，我們可以把一個系統模塊看作一個單一職責的行為者，比如：訂單系統只關注訂單相關的行為，交易系統只關注交易相關的行為，我們也可以把類作為一個單一職責的行為者，比如：訂單類，把訂單相關的 CRUD聚合在一起，支付類，把支付相關的信息聚合在一起。
因此，任何一個軟件模塊都應該只對某一類行為者負責這個定義才更適合單一職責。
最后，單一職責原則是面向對象設計的重要原則之一，它可以提高代碼的可維護性、可讀性和可擴展性，在日常開發中，遵循 SRP可以有效地降低類之間的耦合度，提高系統的穩定性和靈活性，從而寫出更高質量的代碼。
本文鏈接：http://www.www897cc.com/showinfo-26-98188-0.html單一職責到底是什么？十分鐘帶你掌握!
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： Python一個非常實用的庫：Typer
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號