設計原則是軟件開發(fā)的基礎，作為軟件工程師，可以在工具、語言、框架、范式和模式中找到這些設計原則，它們是"優(yōu)秀"、"可讀"代碼的核心支柱，一旦理解了這些原則，就可以在任何地方看到。

洞察和應用這些基本原則的技能是優(yōu)秀工程師和差勁工程師的區(qū)別所在。如果不了解這些基本原則，任何框架或工具都無法幫助你提高編寫優(yōu)秀代碼的質量。此外，如果不了解這些基本原則，你就會成為工具的人質。

本文并不是參考指南，而是一份將需要不斷刷新的核心原則系統(tǒng)化的清單。

抽象（Abstraction）

[抽象](https://en.wikipedia.org/wiki/Abstraction_(computer_science "抽象")是最重要的一般性原則之一。抽象意味著只關注重要部分，而忽略其他細節(jié)。抽象與封裝是相輔相成的，封裝是一種隱藏被抽象部分的實現(xiàn)的方法。

在軟件開發(fā)中，可以將其視為定義一種類型、接口或函數(shù)簽名，作為工作合約。主要好處是不需要知道實現(xiàn)細節(jié)就可以使用某些東西，因此可以更好的專注于對開發(fā)者來說至關重要的東西。

這一原則并不局限于應用開發(fā)。作為開發(fā)者，通過語言語法從操作系統(tǒng)的底層操作中抽象出來。反過來，操作系統(tǒng)通過 CPU、內存、網卡等將語言從底層操作中抽象出來。越深入研究，你就越會明白這只是一個抽象問題。

封裝變化（Encapsulate what varies）

如你所見，抽象可以表現(xiàn)為不同形式--從數(shù)據（實現(xiàn)）抽象到分層抽象。使用抽象的一般原則是"封裝變化"，即確定可能發(fā)生變化的部分，并為其聲明具體接口。這樣，即使內部邏輯發(fā)生變化，客戶端仍可進行相同的交互。

假設我們需要計算貨幣兌換，目前只有兩種貨幣，可以這樣計算：

if (baseCurrency == "USD" and targetCurrency == "EUR") return amount * 0.90;
if (baseCurrency == "EUR" and targetCurrency == "USD") return amount * 1.90;

但將來可能會添加另一種貨幣，這就需要修改客戶端代碼。與其這樣，還不如將所有邏輯抽象并封裝在一個單獨的方法中，并在需要時從客戶端調用該方法。

function convertCurrency(amount, baseCurrency, targetCurrency) {
  if (baseCurrency == "USD" and targetCurrency == "EUR") return amount * 0.90;
  if (baseCurrency == "EUR" and targetCurrency == "USD") return amount * 1.90;
  if (baseCurrency == "USD" and targetCurrency == "UAH") return amount * 38.24;
  …
}

DRY

DRY[2]（don't repeat yourself，不要重復），也被稱為 DIE（duplication is evil，重復是邪惡的），指的是不應該在代碼庫中重復信息或知識。

"每項知識在系統(tǒng)中都必須有單一、明確、權威的表示"

--Andy Hunt，Dave Thomas，The Pragmatic Programmer。

減少重復代碼的好處在于更改和維護的簡便性。如果你在多個地方重復相同的邏輯，發(fā)現(xiàn)錯誤后，很可能會忘記修改其中的某個地方，這將導致看似相同的功能出現(xiàn)不同的行為。反之，找到重復功能，將其抽象為過程、類等形式，賦予有意義的名字，并在需要的地方使用。這樣做可以實現(xiàn)單點更改，最大限度減少對功能的破壞。

KISS

KISS[3]（keep it simple、stupid，保持簡單、愚蠢）一詞是由飛機工程師Kelly Johnson提出的，他向自己的工程團隊提出挑戰(zhàn)，要求他們設計的噴氣式飛機必須能夠在實戰(zhàn)條件下由普通機械師僅使用特定工具進行維修。

其主要理念是注重系統(tǒng)的簡潔性，在只使用真正需要的工具的同時，增加對系統(tǒng)的理解，減少過度設計。

YAGNI

在設計解決方案時，需要考慮兩件事：如何使其更好的適應當前系統(tǒng)，以及如何使其具有可擴展性以滿足未來可能的需求。在第二種情況下，為了更好的可擴展性而過早構建功能的愿望通常是錯誤的：即使你現(xiàn)在認為這樣做可以降低集成成本，但這種代碼的維護和調試可能并不容易，而且會帶來不必要的復雜性。這就違反了前面的原則，增加了解決當前問題的冗余復雜性。此外別忘了，你所假定的功能很有可能在將來并不需要，而你只是在浪費資源。

這就是 YAGNI （You aren’t gonna need it，你不會需要它）的意義所在。不要誤解，你應該考慮解決方案將來會有什么用途，但只有在真正需要的時候才添加代碼。

LoD

得墨忒耳定律[4]（LoD，Law of Demeter），也稱為最少知識原則，或者"不要與陌生人說話"。由于 LoD 通常與 OOP 有關，因此在這種情況下，"陌生人"指的是與當前對象沒有直接關聯(lián)的任何對象。

使用 LoD 的好處在于可維護性，具體表現(xiàn)為避免無關對象之間的直接接觸。

因此，當你與某個對象交互時，如果不符合以下情況之一，就違反了這一原則：

• 當對象是某個類的當前實例時（通過 this 訪問）
• 當對象是類的一部分時
• 當對象通過參數(shù)傳遞給方法時
• 當對象在方法中實例化時
• 當對象在全局范圍可用時

舉個例子，考慮客戶要向銀行賬戶存款的情況。我們最終可能會有三個類--Wallet（錢包）、Customer（客戶）和Bank（銀行）。

class Wallet {
 private decimal balance;

 public decimal getBalance() {
   return balance;
 }

 public void addMoney(decimal amount) {
   balance += amount
 }

 public void withdrawMoney(decimal amount) {
   balance -= amount
 }
}

class Customer {
 public Wallet wallet;

 Customer() {
   wallet = new Wallet();
 }
}

class Bank {
 public void makeDeposit(Customer customer, decimal amount) {
   Wallet customerWallet = customer.wallet;

   if (customerWallet.getBalance() >= amound) {
     customerWallet.withdrawMoney(amount);
     //...
   } else {
     //...
   } 
 }
}

可以在 makeDeposit 方法中看到違反 LoD 的行為。從 LoD 的角度訪問客戶錢包是正確的（盡管從邏輯角度看這是個奇怪的行為）。但在這里，銀行對象調用了客戶錢包對象的 getBalance 和 withdrawMoney，因此是在與陌生人（錢包）而不是朋友（客戶）對話。

下面是修復方法：

class Wallet {
 private decimal balance;

 public decimal getBalance() {
   return balance;
 }

 public boolean canWithdraw(decimal amount) {
   return balance >= amount;
 }

 public boolean addMoney(decimal amount) {
   balance += amount
 }

  public boolean withdrawMoney(decimal amount) {
   if (canWithdraw(amount)) {
     balance -= amount;
   }
 }
}

class Customer {
 private Wallet wallet;

 Customer() {
   wallet = new Wallet();
 }

 public boolean makePayment(decimal amount) {
   return wallet.withdrawMoney(amount);
 }
}

class Bank {
 public void makeDeposit(Customer customer, decimal amount) {
   boolean paymentSuccessful = customer.makePayment(amount);

   if (paymentSuccessful) {
     //...
   } else {
     //...
   }   
 }
}

現(xiàn)在，與客戶錢包的所有交互都通過客戶對象進行。這種抽象有利于松散耦合，能更輕松的修改Wallet和Customer類內部的邏輯（Bank對象不應關心Customer的內部實現(xiàn)）以及測試。

一般來說，當一個對象有兩個以上的點時，LoD 就會失敗，比如 object.friend.stranger 而不是 object.friend。

SoC

關注點分離[5]（SoC，Separation of Concerns）原則建議根據關注點的不同將系統(tǒng)分成較小的部分，這里的"關注點"指的是系統(tǒng)的某個顯著特征。

例如，如果你正在為某個領域建模，那么每個對象都可以被視為一個特殊的關注點。在分層系統(tǒng)中，每一層都有自己的關注點。在微服務架構中，每個服務都有自己的目的。這個列表可以無限繼續(xù)下去。

SoC 的主要特點是：

• 確定系統(tǒng)關注的問題；
• 將系統(tǒng)分為不同部分，獨立解決這些問題；
• 通過明確定義的接口連接這些組件。

在這種方式下，關注點分離與抽象原則非常相似。遵循 SoC 原則的結果是：易于理解、模塊化、可重用、基于穩(wěn)定的接口和可測試代碼。

SOLID

SOLID 原則是Robert Martin提出的五項設計原則，旨在明確面向對象編程的初始約束，并使程序更具靈活性和適應性。

(1) 單一責任原則（Single responsibility principle）

"類應該有且只有一個變更的理由。"

換句話說：

"把因相同原因而變化的事物聚集在一起。把因不同原因而變化的事物分開"。

和 SoC 非常像，是吧？這兩個原則的區(qū)別在于，SRP 的目標是類級分離，而 SoC 則是一種通用方法，同時適用于高層（如層、系統(tǒng)、服務）和低層（類、函數(shù)等）抽象。

單一責任原則具有 SoC 的所有優(yōu)點，尤其是促進了高內聚和低耦合，避免了"上帝對象"的反模式。

(2) 開閉原則（Open-closed principle）

"軟件實體應該可以擴展，但不可修改。"

實施新功能時，應避免對現(xiàn)有代碼進行破壞性修改。

當你可以擴展某個類并添加所需修改時，這個類就被認為是開放的。如果某個類有明確定義的接口，并且將來不會改變，即可以被別的代碼所使用，那么這個類就被認為是封閉的。

試想一個經典的 OOP 繼承：你創(chuàng)建一個父類，然后用附加了功能的子類對其進行擴展。然后出于某種原因，你決定改變父類的內部結構（例如，添加一個新字段或刪除某些方法），而這個結構也可以訪問或直接影響派生類。這樣做就違反了這一原則，因為現(xiàn)在你不僅需要修改父類，還需要調整子類以適應新的變化。出現(xiàn)這種情況是因為沒有正確應用信息隱藏。相反，如果你通過公共屬性或方法給子類定義穩(wěn)定的契約，那么只要不影響該契約，就可以自由改變內部結構。

這一原則鼓勵客戶端依賴抽象（如接口或抽象類）而非實現(xiàn)（具體類）。通過這種方式，依賴抽象的客戶端被認為是封閉的，但同時又是開放的，因為所有符合抽象的新修改都可以無縫集成到客戶端中。

再舉一個例子。假設我們正在開發(fā)折扣計算邏輯。到目前為止，只有兩種折扣。在應用開閉原則之前：

class DiscountCalculator {
 public double calculateDiscountedPrice(double amount, DiscountType discount) {
   double discountAmount = 15.6;
   double percentage = 4.0;
   double appliedDiscount;

   if (discount == 'fixed') {
     appliedDiscount = amount - discountAmount;
   }

   if (discount == 'percentage') {
     appliedDiscount = amount * (1 - (percentage / 100))  ;
   }

   // logic
 }
}

現(xiàn)在，客戶端（DiscountCalculator）依賴于外部 DiscountType。如果添加新的折扣類型，就需要進入客戶端邏輯并對其進行擴展。這是不可取的行為。

在應用了開閉原則之后：

interface Discount {
 double applyDiscount(double amount);
}

class FixedDiscount implements Discount {
 private double discountAmount;

 public FixedDiscount(double discountAmount) {
     this.discountAmount = discountAmount;
 }

 public double applyDiscount(double amount) {
     return amount - discountAmount;
 }
}

class PercentageDiscount implements Discount {
 private double percentage;

 public PercentageDiscount(double percentage) {
     this.percentage = percentage;
 }

 public double applyDiscount(double amount) {
     return amount * (1 - (percentage / 100));
 }
}

class DiscountCalculator {
 public double calculateDiscountedPrice(double amount, Discount discount) {
   double appliedDiscount = discount.applyDiscount(amount);
   // logic
 }
}

這樣就可以利用開閉原則和多態(tài)性，而不是添加多個 if 語句來確定某些實體的類型和未來行為。所有實現(xiàn) Discount 接口的類在公共 applyDiscount 方法方面都是封閉的，但與此同時，在修改內部數(shù)據時又是開放的。

里氏替代原則（Liskov substitution）

"派生類必須可替代基類。"

或者更正式的表述：

"讓 φ(x) 成為 T 類型對象 x 的可證明屬性。那么對于 S 類型的對象 y，φ(y) 應該為真，其中 S 是 T 的子類型"（Barbara Liskov 和 Jeannette Wing，1994 年）

簡單來說，當你擴展某個類時，不應破壞它所建立的契約。所謂"毀約"，是指未能滿足以下要求：

• 不要更改派生類中的參數(shù)：子類應符合父類的方法簽名，即接受與父類相同的參數(shù)，或接受更抽象的參數(shù)。
• 不要改變派生類的返回類型：子類應返回與父類相同的類型，或返回更具體的（子類型）參數(shù)。
• 不要在派生類中拋出異常：除非父類拋出異常，否則子類不應在其方法中拋出異常。這種情況下，異常類型應與父類的異常類型相同或屬于父類異常的子類型。
• 不要在派生類中強化先決條件：子類不應通過將其工作限制在某些條件下來改變預期客戶端的行為，例如，在父類中，能夠接受任意長度字符串，但在子類中，只能接受不超過 100 個字符的字符串。
• 不要弱化派生類中的后置條件：子類不應改變預期行為，允許減少某些工作，例如，操作后不清理狀態(tài)，不關閉套接字等。
• 不要削弱派生類中的不變性：子類不應改變父類中定義的條件，例如，不要重新分配父類的字段，因為子類可能沒有意識到圍繞該字段的全局邏輯概念。

接口隔離（Interface segregation）

"提供客戶端專用的細粒度接口。"

任何代碼都不應依賴不需要的方法。如果客戶端不使用對象的某些行為，為什么要強迫它依賴這些行為？同樣，如果客戶端不使用某些方法，為什么要強迫實現(xiàn)者提供這些功能？

將"胖"的接口分解為更具體的接口。如果更改了具體的接口，不會影響到無關的客戶端。

依賴倒置（Dependency inversion）

"依賴抽象，而非實現(xiàn)。"

Bob大叔將這一原則描述為嚴格遵守 OCP 和 LSP：

"在本專欄中，我們將討論 OCP 和 LSP 的結構化定義。嚴格使用這些原則所產生的結構本身可以概括為一個原則。我稱之為"依賴倒置原則"（DIP，The Dependency Inversion Principle）"。- Robert Martin

依賴倒置主要包括兩層概念：

• 高層模塊不應依賴于低層模塊，兩者都應依賴于抽象。
• 抽象不應依賴細節(jié)，細節(jié)應該依賴于抽象。

舉例來說，假設我們正在開發(fā)一個用戶管理服務，決定使用 PostgreSQL 作為數(shù)據持久化。

class UserService {
 private PostgresDriver postgresDriver;

 public UserService(PostgresDriver postgresDriver) {
     this.postgresDriver = postgresDriver;
 }

 public void saveUser(User user) {
   postgresDriver.query("INSERT INTO USER (id, username, email) VALUES (" + user.getId() + ", '" + user.getUsername() + "', '" + user.getEmail() + "')");
 }

 public User getUserById(int id) {
   ResultSet resultSet = postgresDriver.query("SELECT * FROM USER WHERE id = " + id);
   User user = null;
   try {
       if (resultSet.next()) {
           user = new User(resultSet.getInt("id"), resultSet.getString("username"), resultSet.getString("email"));
       }
   } catch (SQLException e) {
       e.printStackTrace();
   }
   return user;
 }

 // ...
}

目前，UserService 與其依賴關系（PostgresDriver）緊密耦合。但后來我們決定遷移到 MongoDB 數(shù)據庫。由于 MongoDB 與 PostgreSQL 不同，我們需要重寫 UserService 類中的每個方法。

解決辦法是引入接口：

interface UserRepository {
 void saveUser(User user);
 User getUserById(int id);
 // ...
}

class UserPGRepository implements UserRepository {
 private PostgresDriver driver;

 public UserPGRepository(PostgresDriver driver) {
   this.driver = driver;
 }

 public void saveUser(User user) {
   // ...
 }

 public User getUserById(int id) {
   // ...
 }
 // ...
}

class UserMongoRepository implements UserRepository {
 private MongoDriver driver;
  public UserPGRepository(MongoDriver driver) {
   this.driver = driver;
 }

 public void saveUser(User user) {
   // ...
 }

 public User getUserById(int id) {
   // ...
 }
 // ...
}

class UserService {
 private UserRepository repository;

 public UserService(UserRepository database) {
     this.repository = database;
 }

 public void saveUser(User user) {
   repository.saveUser(user);
 }

 public User getUserById(int id) {
   return repository.getUserById(id);
 }
 // ...
}

現(xiàn)在，高層模塊（UserService）依賴于抽象模塊（UserRepository），而抽象模塊并不依賴于細節(jié)（PostgreSQL 的 SQL API 和 MongoDB 的 Query API），而只依賴于為客戶端構建的接口。

最后提一下，要實現(xiàn)依賴反轉，可以使用依賴注入技術：Demystifying Dependency Injection: An Essential Guide for Software Developers[6]

GRASP

[一般責任分配原則](https://en.wikipedia.org/wiki/GRASP_(object-oriented_design "一般責任分配原則"))（GRASP，General Responsibility Assignment Principles）是 Craig Larman 在其著作 Applying UML and Patterns 中提出的9項用于面向對象設計的原則。

與 SOLID 類似，這些原則并不是從零開始建立，而是在 OOP 的背景下由久經考驗的編程準則組成的。

(1) 高內聚（High cohesion）

"將相關功能和職責集中在一起。"

高內聚原則的重點是保持復雜度可控。在這種情況下，內聚度是對象的職責緊密程度。如果一個類的內聚度較低，就意味著它在做與其主要目的無關的工作，或者在做可以委托給其他子系統(tǒng)的工作。

一般來說，高內聚設計的類只有少量方法，而且方法的功能都高度相關。這樣做可以提高代碼的可維護性、可讀性和重用性。

(2) 低耦合（Low coupling）

"減少不穩(wěn)定組件之間的聯(lián)系。"

這一原則旨在降低組件之間的依賴性，從而防止代碼變更帶來副作用。這里的耦合度是指一個組件對另一個組件的依賴程度（知道或依賴）。

具有高耦合度的程序組件彼此依賴性非常強。如果有一個耦合度很高的類，它的變化會導致系統(tǒng)其他部分的局部變化，反之亦然。這樣的設計限制了代碼復用，并且需要花更多時間來理解。另一方面，低耦合支持設計獨立性更強的類，從而減少變更帶來的影響。

耦合和內聚原則是相輔相成的。如果兩個類的內聚性很高，那么它們之間的聯(lián)系通常很弱。同樣，如果這些類之間的耦合度較低，顧名思義，它們的內聚度也較高。

(3) 信息專家（Information expert）

"以數(shù)據定責任。"

信息專家模式回答了應該如何分配了解某一信息或完成某些工作的責任這一問題。按照這種模式，可以直接獲取所需信息的對象被視為該信息的信息專家。

還記得在客戶和銀行之間應用得墨忒耳定律的例子嗎？本質上是一樣的：

• Wallet 類是了解余額和管理余額的信息專家。
• Customer 類是有關其內部結構和行為的信息專家。
• Bank 類是銀行領域的信息專家。

履行一項職責往往需要收集系統(tǒng)不同部分的信息。因此，應該有中介信息專家。有了他們，對象就能保存自己的內部信息，從而提高封裝性，降低耦合度。

(4) 構建者（Creator）

"將構建對象的責任分配給密切相關的類。"

誰應該負責構建新的對象實例？根據構建者模式，要構建 x 類的新實例，構建者類應具備以下屬性之一：

• 聚合 x；
• 包含 x；
• 記錄 x；
• 密切使用 x；
• 擁有 x 所需的初始化數(shù)據。

這一原則促進了低耦合，因為如果你為某個對象找到了合適的構建者，即一個已經與該對象有某種關聯(lián)的類，就不會增加彼此之間的關聯(lián)性。

控制器（Controller）

"將處理系統(tǒng)信息的責任分配給特定的類。"

控制器是系統(tǒng)對象，負責接收用戶事件并將其委托給領域層。它是第一個從用戶界面接收服務請求的元素。控制器通常用于處理類似的用例，例如 UserController 用于管理用戶實體交互。

記住，控制器不應從事任何業(yè)務工作。控制器應盡可能精簡，應將工作委托給相應的類，而不是自己負責。

例如，我們可以在類似 MVC 的設計模式中找到控制器。MVC 引入了控制器，作為負責處理視圖和模型之間交互的中間部分，而不是讓模型和視圖直接通信。有了這個組件，模型就不再受外部交互的影響。

(1) 間接（Indirection）

"為了降低耦合，將責任分配給中介類。"

Butler Lampson 有一句名言："計算機科學中的所有問題都可以通過加一個間接層來解決"。

間接原則與依賴反轉原則的理念相同：在兩個組件之間引入中介，使它們不產生直接交互。這樣做的目的是支持弱耦合，以及其他一些優(yōu)點。

(2) 多態(tài)（Polymorphism）

"當類似行為因類型不同而不同時，通過多態(tài)將職責分配給不同行為的類型。"

如果看到使用 if/switch 語句檢查對象類型的代碼，那就說明可能欠缺對多態(tài)性的應用。當需要加入新功能來擴展代碼時，如果必須在條件檢查的地方添加新的 if 語句，說明這是個糟糕的設計。

對具有類似行為的不同類應用多態(tài)性原則，可以統(tǒng)一不同類型，構造可互換的軟件組件，每個組件負責特定功能。根據語言的不同，可以有多種方法，但常見的是實現(xiàn)相同的接口或使用繼承，特別是為不同對象的方法賦予相同的名稱。最終可獲得可插拔、易于擴展的組件，并且無需更改無關代碼。

與開閉原則一樣，正確使用多態(tài)也很重要。只有在確定某些組件將會或可能發(fā)生變化時，才需要使用多態(tài)。例如，不需要在語言內部類或框架之上創(chuàng)建一個實現(xiàn)多態(tài)的抽象概念。它們已經很穩(wěn)定了，你只是在做無謂的工作。

(3) 純粹構件（Pure Fabrication）

"為了支持高內聚，將責任分配給適當?shù)念悺?

有時，為了遵循高內聚/低耦合原則，需要實現(xiàn)現(xiàn)實世界中并不存在的實體。從這個角度看，你是在創(chuàng)造一個虛構的東西，一個在領域中并不存在的東西。之所以說它純粹，是因為這個實體的職責設計得很清楚。Craig Larman 建議在信息專家應用邏輯錯誤時使用這一原則。

例如，控制器模式就是一種純粹構件，DAO 或存儲庫也是一種構件。這些類并不是某些領域獨有，但卻方便了開發(fā)人員。雖然我們可以將數(shù)據訪問邏輯直接放在領域類中（因為有這方面的專家），但這會違反高內聚，因為數(shù)據管理邏輯與領域對象的行為方式沒有直接關系。同時因為需要依賴數(shù)據庫接口，耦合度也會增加。不同領域實體的數(shù)據管理邏輯相似，代碼重復率可能會很高。換句話說，這會導致在一個地方混合不同的抽象概念。

使用純粹構件類的好處是將相關行為歸類到對象中，這在現(xiàn)實世界中是無可替代的，可以實現(xiàn)有助于代碼重用的良好設計，并降低對不同職責的依賴性。

(4) 受控變更（Protected variations）

"通過引入穩(wěn)定的契約來保護可預測的變更。"

為了在不破壞其他部分的情況下提供未來的變化，需要引入穩(wěn)定的契約來阻止不確定的影響。這一原則強調了前面討論過的在不同對象之間分離責任的原則的重要性：需要通過間接依賴來輕松的在不同實現(xiàn)之間切換，需要通過信息專家來決定誰應該負責滿足需求，需要在設計系統(tǒng)時考慮到多態(tài)性，以引入不同的可插拔解決方案，等等。

受控變更原則是一個核心概念，驅動著其他設計模式和原則。

"從一個層面上講，開發(fā)人員或架構師的成熟體現(xiàn)在他們對實現(xiàn)受控變更的更廣泛機制的了解不斷增加，能夠選擇值得付出努力的合適的受控變更，并有能力選擇合適的受控變更解決方案。在早期階段，人們學習數(shù)據封裝、接口和多態(tài)性，這些都是實現(xiàn)受控變更的核心機制。之后，人們會學習到基于規(guī)則的語言、規(guī)則解釋器、反射和元數(shù)據設計、虛擬機等技術，所有這些技術都可以用來防止某些變更"。- Craig Larman，Applying UML and Patterns。

結論

我相信，在閱讀本文之前，你已經在不知不覺中運用了其中的某些原則。現(xiàn)在，你知道了更多細節(jié)，溝通起來就更容易了。

你可能已經注意到，其中某些原則有相同的基本理念。本質上來說，確實如此。例如，信息專家、SoC、高內聚低耦合、SRP、接口隔離等，都有相同的觀點，即分離不同軟件組件之間的關注點。這樣做是為了實現(xiàn)受控變更、依賴反轉和間接依賴，以獲得可維護、可擴展、可理解和可測試的代碼。

與任何工具一樣，這只是一個指導方針，而不是嚴格的規(guī)則。關鍵是要了解其中的利弊得失，并做出明智的決定。