# Item 32: 確保 public inheritance 模擬 "is-a" 作者：Scott Meyers 譯者：fatalerror99 (iTePub's Nirvana) 發布：http://blog.csdn.net/fatalerror99/ 在 Some Must Watch While Some Must Sleep (W. H. Freeman and Company, 1974) 這本書中，William Dement 講述了一個他試圖讓他的學生的記住他的課程中最重要的東西的故事。書中聲稱，他告訴他的班級，一般的英國中小學生對于 1066 年發生的 Hastings 戰爭的歷史并沒有什么了解。他著重強調，如果一個孩子記住了一點兒什么的，他或者她也就是記住了 1066 這個年代。對于上他的課程的學生，Dement 滔滔不絕地講，其中只有很少的重要信息，包括安眠藥卻引起了失眠這樣充滿趣味的事情。他希望他的學生即使忘記課程中討論的其它每一件事，也能記住這些很少的重大事件，而且他在整個學期再三地回顧這些基礎的內容。 在課程結束的時候，期末考試的最后一道題是：“寫下從這個課程中得到的，你一生都將確切地記住的一件事。”當 Dement 給這次考試打分的時候，他幾乎暈了過去。幾乎每一個人都寫了"1066"。 因此，我一再煞費苦心地向你宣揚，使用 C++ 語言進行 object-oriented programming 時唯一最重要規則就是：public inheritance（公開繼承）意味著 "is-a"。要讓這個規則刻骨銘心。 如果你寫了一個 class D ("Derived") 從 class B ("Base") 公開繼承，你就是在告訴 C++ 編譯器（以及你的代碼的讀者）每一個類型為 D 的對象也是一個類型為 B 的對象，但是反之則不然。你就是在說 B 描繪了一個比 D 更一般的概念，D 描述了一個比 B 更特殊的概念。你就是在聲稱一個類型為 B 的對象可以使用的任何地方，一個類型為 D 的對象一樣可以使用，因為每一個類型為 D 的對象也就是一個類型為 B 的對象。另一方面，如果你需要一個類型為 D 的對象，一個類型為 B 的對象則不行：每一個 D 都是一個 B，但是反之則不然。 C++ 堅持對 public inheritance 的這一解釋。考慮這個例子： ``` class Person {...}; class Student: public Person {...}; ``` 我們從日常的經驗知道每一個學生都是一個人，但并不是每一個人都是一個學生。這就是由這個繼承體系嚴格確定的意義。我們期望每一件對于人來說成立的事情——例如，他或她有一個出生日——對于一個學生來說也成立。我們不期望每一件對于學生來說成立的事情——例如，他或她在一所特定的學校注冊——對于普通人來說也成立。一個人的概念比一個學生的概念更普通，一個學生一個專門類型的人。 在 C++ 領域中，任何期望引數類型為 Person（或 pointer-to-Person 或 reference-to-Person）的函數都可以接受一個 Student object（或 pointer-to-Student 或 reference-to-Student）： ``` void eat(const Person& p); // anyone can eat void study(const Student& s); // only students study Person p; // p is a Person Student s; // s is a Student eat(p); // fine, p is a Person eat(s); // fine, s is a Student, // and a Student is-a Person study(s); // fine study(p); // error! p isn't a Student ``` 這一點只對 public inheritance 才成立。只有 Student 以 public 方式從 Person 派生，C++ 才有我所描述的行為。private inheritance 意味著完全不同的其它事情（參見 Item 39），而 protected inheritance 究竟意味什么使我困惑至今。 public inheritance 和 is-a 等價聽起來簡單，但有時你的直覺會誤導你。例如，企鵝是一種鳥沒有問題，而鳥能飛也沒有問題。如果我們天真地試圖用 C++ 來表達，我們就會得到： ``` class Bird { public: virtual void fly(); // birds can fly ... }; class Penguin:public Bird { // penguins are birds ... }; ``` 突然間我們遇到了麻煩，因為這個繼承體系表示企鵝能飛，我們知道這不是真的。發生了什么呢？ 在這種情況下，我們成了不嚴謹的語言——英語的犧牲品。當我們說鳥能飛的時候，我們的意思并非是說所有種類的鳥都能飛，我們不過是說，大體上，鳥有飛的能力。如果我們說得更準確些，我們應該承認有幾種不能飛的鳥，并提出如下繼承體系，它對事實的模擬要好得多： ``` class Bird { ... // no fly function is declared }; class FlyingBird: public Bird { public: virtual void fly(); ... }; class Penguin: public Bird { ... // no fly function is declared }; ``` 這個繼承體系比最初的設計更忠實于我們真正知道的東西。 至此我們還是沒有完全做好關于這些鳥的事情，因為對于某些軟件系統來說，可能并不需要區分能飛的和不能飛的鳥。如果你的應用程序對于鳥喙和鳥翼做了很多處理，而不打算對飛行做什么處理的話，最初的 two-class 的繼承體系可能完全適用。它是對“沒有一個適用于所有軟件的完美設計”這樣的事實的一個簡單反映。最好的設計依賴于系統究竟期望做什么，無論現在還是未來。如果你的程序對飛行一無所知，而且也不期望以后能知道些什么，那么不分辨能飛與不能飛的鳥可能就是一個非常完美的設計決策。事實上，它可能比區分它們的設計更為可取，因為你試圖模擬的世界中就沒有這樣一種區分。。 對于如何處理我所說的“所有的鳥能飛，企鵝是鳥，企鵝不能飛，啊……哦……”的問題，還有另一種思想觀念。那就是為企鵝重定義 fly 函數，以便讓它產生一個運行時錯誤。 ``` void error(const std::string& msg); // defined elsewhere class Penguin: public Bird { public: virtual void fly() { error("Attempt to make a penguin fly!");} ... }; ``` 認可“這里所說的一些事情與你所想的可能不同”是很重要的。這不是說“企鵝不能飛”。而是說“企鵝能飛，但對它試圖真的這樣做就是一個錯誤”。 你能說出其中的區別嗎？從錯誤被發覺時間方面看。“企鵝不能飛”的禁令可以由編譯器強令執行，但是對“讓企鵝真的去飛是一個錯誤”的規約的違反，只有在運行時才能被發覺。 為了表達“企鵝不能飛”這個限制，你要確保不要為 Penguin 對象定義這樣的函數： ``` class Bird { ... // no fly function is declared }; class Penguin: public Bird { ... // no fly function is declared }; ``` 如果你現在試圖讓企鵝飛，編譯器將因為你的違例而懲罰你： ``` Penguin p; p.fly(); // error! ``` 這與你采用產生運行時錯誤的方法，得到完全不同的行為。使用那個方法，關于對 p.fly 的調用，編譯器一言不發。Item 18 解釋了好的接口可以在編譯時防止非法代碼，所以你應該用通過編譯器阻止企鵝飛翔企圖的設計代替只在運行時檢測的設計 也許你會承認你的鳥類學知識可能不足，但是你對自己對基本幾何學的掌握很自信，是嗎？我的意思是說，矩形和正方形能有多么復雜？ 好吧，回答這個簡單的問題：應該讓 class Square 從 class Rectangle 公開繼承嗎？  “咄！”你說，“當然應該！每一個人都知道一個正方形就是一個矩形，但是反過來就不一定了。”這完全正確，至少在學校里是。但是我不認為我們現在還在學校里。 考慮如下代碼： ``` class Rectangle { public: virtual void setHeight(int newHeight); virtual void setWidth(int newWidth); virtual int height() const; // return current values virtual int width() const; ... }; void makeBigger(Rectangle& r) // function to increase r's area { int oldHeight = r.height(); r.setWidth(r.width() + 10); // add 10 to r's width assert(r.height() == oldHeight); // assert that r's } // height is unchanged ``` 很清楚，斷言應該永遠不會失敗。makeBigger 僅僅改變了 r 的寬度，它的高度始終沒有變化。 現在，考慮以下代碼，使用 public inheritance 使得 squares 可以像 rectangles 一樣進行處理： ``` class Square: public Rectangle {...}; Square s; ... assert(s.width() == s.height()); // this must be true for all squares makeBigger(s); // by inheritance, s is-a Rectangle, // so we can increase its area assert(s.width() == s.height()); // this must still be true // for all squares ``` 和剛才那個一樣明顯，第二個斷言也應該永遠不會失敗。根據定義，正方形的寬度和高度是相等的。 但是，現在有一個問題，我們怎樣才能協調以下斷言？ * 調用 makeBigger 之前，s 的高度和它的寬度相等； * 在 makeBigger 內，s 的寬度發生變化，但是它的高度沒有變化； * 從 makeBigger 返回之后，s 的高度還要和它的寬度相等。（注意 s 是通過 by reference 方式傳入 makeBigger 的，所以 makeBigger 能改變 s 自身，而不是 s 的拷貝。） 嘟嘟？ 歡迎來到 public inheritance 的奇妙世界，你在其它學習領域——包括數學——中發展起來的本能，可能不再像你所期望的那樣幫助你。在這種情況下，基本的難點在于一些適用于矩形（它的寬度可以獨立于他的高度而自行變化）的事情不適用于正方形（它的寬度和高度必須相等）。但是 public inheritance 斷言，適用于 base class objects（基類對象）的每一件事——每一件事！——也適用于 derived class objects（派生類對象）。在矩形和正方形的情況下（還有 Item 38 中一個包含 sets 和 lists 的例子），這個斷言失效，所以用 public inheritance 模擬它們的關系是完全錯誤的。編譯器允許你這樣做，但是就像我們已經看到的，它不能保證代碼的行為正確。每一個程序員都必須認識到，僅僅通過編譯的代碼，并不意味著它可以工作。 不必憂慮你在過去這些年發展起來的軟件直覺在你走近 object-oriented design 時失效。那些知識依然是有價值的，但是現在你應該在你的設計候選武器庫中加入 inheritance，你還必須在你的直覺中加入新的洞察力來指導你正確使用 inheritance。當某個人向你展示一個幾頁長的函數時，你可能會及時地從 Penguin 繼承自 Bird 或 Square 繼承自 Rectangle 得到有趣的感覺。它可能是接近事實的正確方法，只是不太像而已。 is-a 關系并不是能存在于兩個 classes 之間的唯一關系。另外兩個常見的 inter-class 關系是 "has-a" 和 "is-implemented-in-terms-of"。這些關系將在 Item 38 和 39 中考慮。因為用這些其它重要關系中的一個來不正確地模擬 is-a 而造成的 C++ 設計錯誤并不罕見，所以你應該確保你理解了這些關系之間的不同，并知道在 C++ 中如何才能用它們做最好的模擬。 Things to Remember * public inheritance 意味著 "is-a"。適用于 base classes 的每一件事也適用于 derived classes，因為每一個 derived class object 都是一個 base class object。