《C++程式設計規範：101條規則、準則與最佳實踐》——2.6盡量減少全局和共享資料

本節書摘來自異步社群出版社《c++程式設計規範：101條規則、準則與最佳實踐》一書中的第2章，第2.6節，作者：【加】herb sutter , 【羅】andrei，更多章節内容可以通路雲栖社群“異步社群”公衆号檢視。

摘要

共享會導緻沖突：避免共享資料，尤其是全局資料。共享資料會增加耦合度，進而降低可維護性，通常還會降低性能。

讨論

這裡的論述比第18條的具體讨論更加通用。

避免使用名字空間作用域中具有外部連接配接的資料或者作為靜态類成員的資料。這些資料會使程式邏輯變得更加複雜，使程式不同的（而且可能更糟，距離較遠的）部分耦合得更加緊密。共享資料對單元測試會産生不良影響，因為使用共享資料的代碼片斷的正确性不僅取決于資料變化的過程，更取決于以後會使用該資料的未知代碼區域的機能。

全局名字空間中的對象名稱還會污染全局名字空間。

如果必須使用全局的、名字空間作用域的或者靜态的類對象，一定要仔細地對其進行初始化。在不同編譯機關中這種對象的初始化順序是未定義的，正确處理它們需要特殊的技術（參閱本條的參考文獻）。初始化順序規則是非常難于掌握的，應該盡量避免使用；如果不得不用，應該充分了解，謹慎使用。

名字空間作用域中的對象、靜态成員對象或者跨線程或跨程序共享的對象會減少多線程和多處理器環境中的并行性，往往是産生性能和可伸縮性瓶頸的原因（見第7條）。為“無共享”而奮鬥吧，用通信方式（比如消息隊列）代替資料共享。

應該盡量降低類之間的耦合，盡量減少互動（參閱[cargill92]）。

例外情況

程式範圍的設施cin、cout和cerr比較特殊，其實作方式很特别。工廠類必須維護一個系統資料庫，記錄建立給定類型時要調用哪個函數，而且通常應該有一個用于整個程式的系統資料庫（但最好是屬于工廠類，而不是屬于共享全局對象，見第11條）。

跨線程共享對象的代碼應該總是将對這些共享對象的所有通路序列化（見第12條并參閱[sutter04c]）。

參考文獻

[cargill92] pp.126.136,169-173 ● [dewhurst03] §3 ● [lakos96] §2.3.1 ● [mcconnell93] §5.1-4 ● [stroustrup00] §c.10.1 ● [sutter00] §47 ● [sutter02] §16, appendix a ● [sutter04c] ● [sutthysl03]