類必須實現不變式（Classes Should Enforce Invariants）

Bjarne Stroustrup: 我的基本原則式真正的類必須有一個介面，有一個隱含的不變式（invariant）

Bill Venners: 不變式（invariant）是什麼東西？

Bjarne Stroustrup: 什麼使一個物件（object）有效？是不變式（invariant）。
我以vector舉例說明。vector知道自己有n個元素（element），vector也知道自己有一個指標指向這些元素。以上兩點就是不變式（invariant）。如果vector實際上竟然有n+1個元素，就出問題了。如果vector包含的指標為0，也表示有bug。所以在定義一個類前，你必須明確什麼是不變式（invariant）

• 類的介面必須體現了不變式（invariant）。

如果類的成員函式（member function）不能體現不變式，也許這個函式應該放到類的外面比較好。
牢記類的不變式，你就能得到一個簡潔而小的介面，易於理解和維護。

Bill Venners: 不變式（invariant）是建立類的必要條件？因為類的責任就是維護不變式（invariant）？

Bjarne Stroustrup: 說得對。

Bill Venners: 不變式就是類中的各資料間的關係。

Bjarne Stroustrup: 對。如果任何資料都可以隨意定義自己的值，就沒有必要建立類。使用結構體（structure）就行了。考慮有一個數據結構只有姓名和地址兩個欄位，如果隨便什麼字串都可以作為有效的姓名或者地址。那麼結構體（structure）就夠了。把姓名和地址作為私有成員封裝到一個類中，再提供一堆訪問私有成員的介面函式，是很愚蠢的。更愚蠢的就是再去設計一個基類，把這些介面函式設計為虛擬函式。沒有必要。

Bill Venners: 你說沒有必要是因為，資料的表示（representation）有且僅有一種。如果你要把這一種表示（representation）定義為一個函式，意味著將來你會修改表示（representation）。

Bjarne Stroustrup: 對。但是有些表示（representation）並不改變。例如整數，浮點數，複數等等。設計時你不得不做決定。

仍舊以上面的姓名和地址的資料結構為例。接下來，如果你從簡單的結構體（structure）轉向了真正的類。也許你不會把那個類的名字叫做“姓名和地址的組合類”。也許你會把那個類命名為“個人通訊錄”。然後你覺得需要確保“個人通訊錄”中的地址應該是有意義的字串，等等等等。接下來你必須考慮資料的不同表示（representation）。例如姓名欄位定義為私有資料成員嗎？是否需要定義虛擬函式？你必須做設計而不是隨意定義一些類和函式，你需要使用C++的語法來表達你的核心的設計思想，而不是簡單的定義幾個私有資料就完事了。（譯者按：原文為semantics that you are defending，字面意思是保衛你所使用的符號的意義。）

例如，建構函式（constructor）建立了環境供成員函式（member function）在其中操作資料。也就是說，建構函式（constructor）建立了不變式（invariant）。要建立不變式（invariant），你必須獲得資源。解構函式（destructor）做的事情正相反。資源可以是記憶體，檔案，鎖，socket等等。

設計簡單的介面（Designing Simple Interfaces）

Bill Venners: 你剛才說不變式（invariant）幫助你決定了什麼應該進入介面（interface）。你能進一步講一講你是如何設計介面的嗎？

• 如果一個函式有責任維護不變式（invariant)就應該在類中。

Bill Venners: 任何使用了資料，但是不維護（defend）不變式（invariant）的操作，就不需要放在class中？

Bjarne Stroustrup:讓我舉個例子。有時候某些操作必須直接訪問資料才能完成。例如如果你要改變vector的大小，前提條件你必須能夠移動其中的元素（element），修改儲存大小的變數。如果你沒有直接修改資料的許可權，為了完成操作，你必須訪問有許可權的介面函式。但是一個在vector中查詢指定元素的操作最好不要定義為vector的成員函式。

另一個例子是日期類，修改日期類中的年月日資料的操作當然應該是類的成員函式，但是查詢下個週末的函式不應該是成員函式。我曾經看到日期類有60或者70個介面函式。介面函式直接訪問資料。也就是說，如果你修改了類的資料結構，你就必須檢查並修改所有類的介面函式。

如果日期類只有比如說10個必需的介面。你可以把其餘的50個介面建立在這10個介面之上。其餘50個介面可以放在支援庫中（supporting library）。現在這種設計思想已經被普遍接受了。甚至在java中也是如此。

過去二十年我就在鼓吹這種設計思想。但是人們就是喜歡把所有的東西都丟到類和子類中去。比如說前面那個糟糕的日期類。如果你需要一些簡單的工具操作日期，你必須繼承自那個日期類。最後一切都亂七八糟。我僅僅是想自由的組合一些工具進行簡單的操作，為什麼需要繼承呢？如果我想組合使用我的一些工具和你的一些工具，難道我需要定義一個子類，同時繼承你的日期類和我的日期類嗎？繼承引入了不必要的依賴關係。