Effective C++ 條款 23：寧以 non-member non-friend 替換 member 函數

核心觀點

盡量用 non-member non-friend 函數替換 member 函數。 這能增加封裝性、包裝靈活性和功能擴展性。

經典對比：WebBrowser 便利函數

方案 A：member 函數（封裝性差）

class WebBrowser {
public:
    void clearCache();
    void clearHistory();
    void removeCookies();
    // 無 clearEverything！
};

// 非成員、非友元：只能通過 public 接口訪問
void clearBrowser(WebBrowser& wb) {
    wb.clearCache();
    wb.clearHistory();
    wb.removeCookies();
}

為什麼 non-member 更好？

1. 封裝性：訪問 private 的函數越少越好

• member 函數：自動擁有 this 指針，**可訪問所有 private 成員**
• friend 函數：同樣**可訪問所有 private 成員**
• non-member non-friend：**完全無法訪問 private**，只能調用 public 接口

封裝性 = 能看到 private 內容的函數數量的倒數。方案 B 讓類的「信任圈」更小。

2. 包裝靈活性：命名空間天然支持分散定義

// 客戶代碼：無需修改庫代碼即可添加功能
namespace WebBrowserStuff {
    void downloadImages(WebBrowser& wb, const std::vector<URL>& urls) {
        // 使用 wb 的 public 接口實現
    }
}
// 新函數與原有函數無縫整合，像原生一樣使用
WebBrowserStuff::downloadImages(browser, urls);

類對客戶**封閉擴展**（無法添加成員函數），命名空間對客戶**開放擴展**。

關鍵限制：僅適用於 non-member non-friend

• friend 函數：訪問權限等同 member，**封裝性無提升**
• static member 函數：屬於類作用域，**仍增加類的接口面**
• non-member non-friend：完全外部，**零封裝破壞**

實際應用：STL 算法設計哲學

STL 將算法設計為 non-member 函數（std::sort, std::find, std::transform...），而非容器成員函數：