C++代碼提供了足夠的靈活性，因此對于大部分工程師來說都很難把握。本文介紹了寫好C++代碼需要遵循的10個最佳實踐，并在最后提供了一個工具可以幫助我們分析C++代碼的健壯度。原文：10 Best practices to design and implement a C++ class

1. 盡可能嘗試使用新的C++標準

到2022年，C++已經走過了40多個年頭。新的C++標準實際上簡化了許多令人沮喪的細節，提供了新的現代方法來改進C++代碼，但讓開發人員認識到這一點并不容易。

以內存管理為例，這可能是C++中受到最多批評的機制。多年來，對象分配都是由new關鍵字完成的，開發人員一定得記住在代碼的某個地方調用delete。“現代C++”解決了這個問題，并促進了共享指針的使用。

2. 使用命名空間模塊化代碼

現代C++庫廣泛使用命名空間來模塊化代碼庫，它們利用“Namespace-by-feature”方法，按功能劃分命名空間來反映功能集，將單個特性(且僅與該特性)相關的所有內容放到單個命名空間中。從而使得命名空間具有高內聚性和高模塊化，并且耦合最小，緊耦合的項目被放在了一起。

Boost是按特性分組的最佳示例，其包含數千個命名空間，每個命名空間用于對特定的特性進行分組。

3. 抽象

數據抽象是C++中面向對象編程最基本和最重要的特性之一。抽象意味著只顯示基本信息而隱藏細節，數據抽象指的是僅向外部世界提供關于數據的基本信息，隱藏背景細節或實現。

盡管許多書籍、網絡資源、會議演講者和專家都推薦這種最佳實踐，但在很多項目中，這條規則仍然被忽略了，許多類的細節并沒有被隱藏。

4. 類越小越好

具有多行代碼的類型應該被劃分為一組較小的類型。

需要很大的耐心重構一個大的類，甚至可能需要從頭重新創建所有東西。以下是一些重構建議:

BigClass中的邏輯必須被分成更小的類。這些較小的類最終可能成為嵌套在原始God Class中的私有類，God Class的實例對象由較小嵌套類的實例組成。

較小的類劃分應該由God Class負責的多個職責驅動。要確定這些職責，通常需要查找與字段的子集強耦合的方法的子集。

如果BigClass包含的邏輯比狀態多，一個好的選擇是定義一個或幾個不包含靜態字段而只包含純靜態方法的靜態類。純靜態方法是一種只根據輸入參數計算結果的函數，它不讀取或分配任何靜態或實例字段。純靜態方法的主要優點是易于測試。

首先嘗試維護BigClass的接口，并委托調用新提取的類。最后，BigClass應該是一個沒有自己邏輯的純接口，可以為了方便將其保留，也可以將其扔掉，并開始只使用新類。

單元測試可以提供幫助: 在提取方法之前為每個方法編寫測試，以確保不會破壞功能。

5. 每個類盡量提供最少的方法

包含20個以上方法的類可能很難理解和維護。

一個類有許多方法可能是實現了太多責任的癥狀。

也許所面對的類控制了系統中太多的其他類，并且已經超出了應有的邏輯，成為了一個無所不能的類。

6. 加強低耦合

低耦合是理想狀態，可以在應用中進行較少的更改實現程序的某個變更。從長遠來看，可以減少修改、添加新特性的大量時間、精力和成本。

低耦合可以通過使用抽象類或泛型類和方法來實現。

7. 加強高內聚

單一責任原則規定一個類不應該有多于一個更改的理由，這樣的類被稱為內聚類。較高的LCOM值通常可以意味著類的內聚性較差。有幾個LCOM指標，取值范圍為[0-1]。LCOM HS (HS代表Henderson-Sellers)取值范圍為[0-2]。LCOM HS值大于1時需要產生警惕。下面是計算LCOM指標:

LCOM = 1 — (sum(MF)/M*F)
LCOM HS = (M — sum(MF)/F)(M-1)

其中……

M是類中方法的數量(包括靜態方法和實例方法，它還包括構造函數、屬性getter/setter、事件添加/刪除方法)。

F是類中實例字段的數量。

MF是類訪問特定實例字段的方法數量。

Sum(MF)是該類所有實例字段的MF之和。

這些公式背后的基本思想可以表述如下: 如果一個類的所有方法都使用它的所有實例字段，那么這個類就是完全內聚的，這意味著sum(MF)=M*F，然后LCOM = 0和LCOMHS = 0。

LCOMHS值大于1就需要警惕了。

8. 只注釋代碼不能表達的內容

鸚鵡學舌的代碼注釋沒有為讀者提供任何額外的東西。代碼庫中充斥著嘈雜的注釋和不正確的注釋，促使程序員忽略所有的注釋，或者采取積極的措施隱藏它們。

9. 盡量不要用重復的代碼

眾所周知，重復代碼的存在對軟件開發和維護有負面影響。實際上，一個主要缺點是，當為了修復bug或添加新特性而更改重復代碼的實例時，所有對應的代碼必須同時更改。

產生重復代碼最常見的原因是復制/粘貼操作，這種情況下，相似的源代碼出現在兩個或多個地方。許多文章、書籍和網站都警告不要采用這種做法，但有時實踐這些建議并不容易，開發人員還是會選擇簡單的解決方案: 復制/粘貼大法。

使用適當的工具可以容易的從復制/粘貼操作中檢測到重復代碼，但是，在某些情況下，克隆代碼很難被檢測到。

10. 不變性有助于多線程編程

基本上，如果對象在創建之后狀態不變，那么這個對象就是不可變(immutable)的。如果一個類的實例是不可變的，那么該類就是不可變的。

不可變對象極大簡化了并發編程，這是支持使用它的重要理由。想想看，為什么編寫適當的多線程程序是一項艱巨的任務？因為同步線程訪問資源(對象或其他操作系統資源)是很困難的。為什么同步這些訪問很困難？因為很難保證多個線程對多個對象進行的多次寫訪問和讀訪問之間不會出現競爭條件。如果不再有寫訪問會怎么樣？換句話說，如果被線程訪問的對象的狀態沒有改變會怎么樣？就不再需要同步了！

關于不可變類的另一個好處是它們永遠不會違反里氏替換原則(LSP, Liskov Subtitution Principle)，以下是維基百科對LSP的定義:

Liskov的行為子類型的概念定義了可變對象可替換性的概念，也就是說，如果S是T的子類型，那么程序中T類型的對象可以被替換為S類型的對象，而不改變該程序的任何期望屬性(例如，正確性)。

如果沒有公共字段，沒有可以更改其內部數據的方法，并且派生類方法無法更改其內部數據，那么引用對象類就是不可變的。因為值不可變，所以在所有情況下都可以引用相同的對象，不需要復制構造函數或賦值操作符。出于這個原因，建議將復制構造函數和賦值操作符設為私有，或者從boost::noncopyable繼承，或者使用新的C++ 11特性“顯式默認和刪除特殊成員函數”[2]。

如何加強對這些最佳實踐進行檢查?

CppDepend[3]提供了名為CQLinq[4]的代碼查詢語言，可以像數據庫一樣查詢代碼庫。開發人員、設計人員和架構師可以自定義查詢，以便輕松找到容易出現bug的情況。

通過CQLinq，可以結合來自代碼度量、依賴關系、API使用和其他模型的數據來定義非常高級的查詢，以匹配容易出現bug的情況。

例如，分析clang源代碼后，可以檢測到大類:

檢測到有大量方法的類:

或者檢測到內聚性較差的類:

References:

[1] 10 Best practices to design and implement a C++ class: https://issamvb.medium.com/10-best-practices-to-design-and-implement-a-c-class-4326611827e1#:~:text=10%20Best%20practices%20to%20design%20and%20implement%20a,class%20as%20you%20can.%20...%20More%20items...%20

[2] Explicitly defaulted and deleted special member functions: http://en.wikipedia.org/wiki/C%2B%2B11#Explicitly_defaulted_and_deleted_special_member_functions

[3] CppDepend: http://www.cppdepend.com/

[4] CQLinq: https://www.cppdepend.com/cqlinq

編輯：黃飛

?