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

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

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

抽象（Abstraction）

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

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

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

封裝變化（Encapsulate what varies）

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

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

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

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

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，不要重復(fù)），也被稱為 DIE（duplication is evil，重復(fù)是邪惡的），指的是不應(yīng)該在代碼庫中重復(fù)信息或知識。

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

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

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

KISS

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

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

YAGNI

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

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

LoD

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

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

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

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

舉個例子，考慮客戶要向銀行賬戶存款的情況。我們最終可能會有三個類--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 的角度訪問客戶錢包是正確的（盡管從邏輯角度看這是個奇怪的行為）。但在這里，銀行對象調(diào)用了客戶錢包對象的 getBalance 和 withdrawMoney，因此是在與陌生人（錢包）而不是朋友（客戶）對話。

下面是修復(fù)方法：

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類內(nèi)部的邏輯（Bank對象不應(yīng)關(guān)心Customer的內(nèi)部實現(xiàn)）以及測試。

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

SoC

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

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

SoC 的主要特點是：

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

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

SOLID

SOLID 原則是Robert Martin提出的五項設(shè)計原則，旨在明確面向?qū)ο缶幊痰某跏技s束，并使程序更具靈活性和適應(yīng)性。

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

"類應(yīng)該有且只有一個變更的理由。"

換句話說：

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

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

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

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

"軟件實體應(yīng)該可以擴展，但不可修改。"

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

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

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

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

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

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。如果添加新的折扣類型，就需要進入客戶端邏輯并對其進行擴展。這是不可取的行為。

在應(yīng)用了開閉原則之后：

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 方法方面都是封閉的，但與此同時，在修改內(nèi)部數(shù)據(jù)時又是開放的。

里氏替代原則（Liskov substitution）

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

或者更正式的表述：

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

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

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

接口隔離（Interface segregation）

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

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

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

依賴倒置（Dependency inversion）

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

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

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

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

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

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

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 與其依賴關(guān)系（PostgresDriver）緊密耦合。但后來我們決定遷移到 MongoDB 數(shù)據(jù)庫。由于 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），而只依賴于為客戶端構(gòu)建的接口。

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

GRASP

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

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

(1) 高內(nèi)聚（High cohesion）

"將相關(guān)功能和職責(zé)集中在一起。"

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

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

(2) 低耦合（Low coupling）

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

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

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

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

(3) 信息專家（Information expert）

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

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

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

• Wallet 類是了解余額和管理余額的信息專家。
• Customer 類是有關(guān)其內(nèi)部結(jié)構(gòu)和行為的信息專家。
• Bank 類是銀行領(lǐng)域的信息專家。

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

(4) 構(gòu)建者（Creator）

"將構(gòu)建對象的責(zé)任分配給密切相關(guān)的類。"

誰應(yīng)該負責(zé)構(gòu)建新的對象實例？根據(jù)構(gòu)建者模式，要構(gòu)建 x 類的新實例，構(gòu)建者類應(yīng)具備以下屬性之一：

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

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

控制器（Controller）

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

控制器是系統(tǒng)對象，負責(zé)接收用戶事件并將其委托給領(lǐng)域?qū)印Ｋ堑谝粋€從用戶界面接收服務(wù)請求的元素?？刂破魍ǔＳ糜谔幚眍愃频挠美?，例如 UserController 用于管理用戶實體交互。

記住，控制器不應(yīng)從事任何業(yè)務(wù)工作?？刂破鲬?yīng)盡可能精簡，應(yīng)將工作委托給相應(yīng)的類，而不是自己負責(zé)。

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

(1) 間接（Indirection）

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

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

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

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

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

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

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

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

(3) 純粹構(gòu)件（Pure Fabrication）

"為了支持高內(nèi)聚，將責(zé)任分配給適當(dāng)?shù)念悺?

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

例如，控制器模式就是一種純粹構(gòu)件，DAO 或存儲庫也是一種構(gòu)件。這些類并不是某些領(lǐng)域獨有，但卻方便了開發(fā)人員。雖然我們可以將數(shù)據(jù)訪問邏輯直接放在領(lǐng)域類中（因為有這方面的專家），但這會違反高內(nèi)聚，因為數(shù)據(jù)管理邏輯與領(lǐng)域?qū)ο蟮男袨榉绞經(jīng)]有直接關(guān)系。同時因為需要依賴數(shù)據(jù)庫接口，耦合度也會增加。不同領(lǐng)域?qū)嶓w的數(shù)據(jù)管理邏輯相似，代碼重復(fù)率可能會很高。換句話說，這會導(dǎo)致在一個地方混合不同的抽象概念。

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

(4) 受控變更（Protected variations）

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

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

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

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

結(jié)論

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

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

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