牽著老婆滿街逛

Effective C++ 2e Item39

條款39: 避免 "向下轉換" 繼承層次

在當今喧囂的經濟時代，關注一下我們的金融機構是個不錯的主意。所以，看看下面這個有關銀行帳戶的協議類(Protocol class )（參見條款34）：

class Person {  };

class BankAccount {
public:
  BankAccount(const Person *primaryOwner,
              const Person *jointOwner);
  virtual ~BankAccount();

  virtual void makeDeposit(double amount) = 0;
  virtual void makeWithdrawal(double amount) = 0;

  virtual double balance() const = 0;

  

};

很多銀行現在提供了多種令人眼花繚亂的帳戶類型，但為簡化起見，我們假設只有一種銀行帳戶，稱為存款帳戶：

class SavingsAccount: public BankAccount {
public:
  SavingsAccount(const Person *primaryOwner,
                 const Person *jointOwner);
  ~SavingsAccount();

  void creditInterest();                // 給帳戶增加利息

  

};

這遠遠稱不上是一個真正的存款帳戶，但還是那句話，現在什么年代？至少，它滿足我們現在的需要。

銀行想為它所有的帳戶維持一個列表，這可能是通過標準庫（參見條款49）中的list類模板實現的。假設列表被叫做allAccounts：

list<BankAccount*> allAccounts;         // 銀行中所有帳戶

和所有的標準容器一樣，list存儲的是對象的拷貝，所以，為避免每個BankAccount存儲多個拷貝，銀行決定讓allAccounts保存BankAccount的指針，而不是BankAccount本身。

假設現在準備寫一段代碼來遍歷所有的帳戶，為每個帳戶計算利息。你會這么寫：

// 不能通過編譯的循環（如果你以前從沒
// 見過使用 "迭代子" 的代碼，參見下文）
for (list<BankAccount*>::iterator p = allAccounts.begin();
     p != allAccounts.end();
     ++p) {

  (*p)->creditInterest();      // 錯誤!

}

但是，編譯器很快就會讓你認識到：allAccounts包含的指針指向的是BankAccount對象，而非SavingsAccount對象，所以每次循環，p指向的是一個BankAccount。這使得對creditInterest的調用無效，因為creditInterest只是為SavingsAccount對象聲明的，而不是BankAccount。

如果"list<BankAccount*>::iterator p = allAccounts.begin()" 在你看來更象電話線中的噪音，而不是C++，那很顯然，你以前無緣見識過C++標準庫中的容器類模板。標準庫中的這一部分通常被稱為標準模板庫（STL），你可以在條款49和M35初窺其概貌。但現在你只用知道，變量p工作起來就象一個指針，它將allAccounts中的元素從頭到尾循環一遍。也就是說，p工作起來就好象它的類型是BankAccount**而列表中的元素都存儲在一個數組中。

上面的循環不能通過編譯很令人泄氣。的確，allAccounts是被定義為保存BankAccount*，但要知道，上面的循環中它事實上保存的是SavingsAccount*，因為SavingsAccount是僅有的可以被實例話的類。愚蠢的編譯器！對我們來說這么顯然的事情它竟然笨得一無所知。所以你決定告訴它：allAccounts真的包含的是SavingsAccount*：

// 可以通過編譯的循環，但很糟糕
for (list<BankAccount*>::iterator p = allAccounts.begin();
     p != allAccounts.end();
     ++p) {

  static_cast<SavingsAccount*>(*p)->creditInterest();

}

一切問題迎刃而解！解決得很清晰，很漂亮，很簡明，所做的僅僅是一個簡單的轉換而已。你知道allAccounts指針保存的是什么類型的指針，遲鈍的編譯器不知道，所以你通過一個轉換來告訴它，還有比這更合理的事嗎？

在此，我要拿圣經的故事做比喻。轉換之于C++程序員，就象蘋果之于夏娃。

這種類型的轉換 ---- 從一個基類指針到一個派生類指針 ---- 被稱為 "向下轉換"，因為它向下轉換了繼承的層次結構。在剛看到的例子中，向下轉換碰巧可以工作；但正如下面即將看到的，它將給今后的維護人員帶來惡夢。

還是回到銀行的話題上來。受到存款帳戶業務大獲成功的激勵，銀行決定再推出支票帳戶業務。另外，假設支票帳戶和存款帳戶一樣，也要負擔利息：

class CheckingAccount: public BankAccount {
public:
  void creditInterest();    // 給帳戶增加利息

  

};

不用說，allAccounts現在是一個包含存款和支票兩種帳戶指針的列表。于是，上面所寫的計算利息的循環轉瞬間有了大麻煩。

第一個問題是，雖然新增了一個CheckingAccount，但即使不去修改循環代碼，編譯還是可以繼續通過。因為編譯器只是簡單地聽信于你所告訴它們（通過static_cast）的一切：*p指向的是SavingsAccount*。誰叫你是它的主人呢？這會給今后維護帶來第一個惡夢。維護期第二個惡夢在于，你一定想去解決這個問題，所以你會寫出這樣的代碼：

for (list<BankAccount*>::iterator p = allAccounts.begin();
     p != allAccounts.end();
     ++p) {

  if (*p 指向一個 SavingsAccount)
    static_cast<SavingsAccount*>(*p)->creditInterest();
  else
    static_cast<CheckingAccount*>(*p)->creditInterest();

}

任何時候發現自己寫出 "如果對象屬于類型T1，做某事；但如果屬于類型T2，做另外某事" 之類的代碼，就要扇自己一個耳光。這不是C++的做法。是的，在C，Pascal，甚至Smalltalk中，它是很合理的做法，但在C++中不是。在C++中，要使用虛函數。

記得嗎？對于一個虛函數，編譯器可以根據所使用對象的類型來保證正確的函數調用。所以不要在代碼中隨處亂扔條件語句或開關語句；讓編譯器來為你效勞。如下所示：

class BankAccount {  };      // 同上

// 一個新類，表示要支付利息的帳戶
class InterestBearingAccount: public BankAccount {
public:
  virtual void creditInterest() = 0;

  

};

class SavingsAccount: public InterestBearingAccount {

                             // 同上

};

class CheckingAccount: public InterestBearingAccount {

                             // as above

};

用圖形表示如下：

                         BankAccount
                                  ^
                                  |
                 InterestBearingAccount
                                 /\
                                /  \
                               /    \
     CheckingAccount   SavingsAccount

因為存款和支票賬戶都要支付利息，所以很自然地想到把這一共同行為轉移到一個公共的基類中。但是，如果假設不是所有的銀行帳戶都需要支付利息（以我的經驗，這當然是個合理的假設），就不能把它轉移到BankAccount類中。所以，要為BankAccount引入一個新的子類InterestBearingAccount，并使SavingsAccoun和CheckingAccount從它繼承。

存款和支票賬戶都要支付利息的事實是通過InterestBearingAccount的純虛函數creditInterest來體現的，它要在子類SavingsAccount和CheckingAccount中重新定義。

有了新的類層次結構，就可以這樣來重寫循環代碼：

// 好一些，但還不完美
for (list<BankAccount*>::iterator p = allAccounts.begin();
     p != allAccounts.end();
     ++p) {

  static_cast<InterestBearingAccount*>(*p)->creditInterest();

}

盡管這個循環還是包含一個討厭的轉換，但代碼已經比過去健壯多了，因為即使又增加InterestBearingAccount新的子類到程序中，它還是可以繼續工作。

為了完全消除轉換，就必須對設計做一些改變。一種方法是限制帳戶列表的類型。如果能得到一列InterestBearingAccount對象而不是BankAccount對象，那就太好了：

// 銀行中所有要支付利息的帳戶
list<InterestBearingAccount*> allIBAccounts;

// 可以通過編譯且現在將來都可以工作的循環
for (list<InterestBearingAccount*>::iterator p =
        allIBAccounts.begin();
     p != allIBAccounts.end();
     ++p) {

  (*p)->creditInterest();

}

如果不想用上面這種 "采用更特定的列表" 的方法，那就讓creditInterest操作使用于所有的銀行帳戶，但對于不用支付利息的帳戶來說，它只是一個空操作。這個方法可以這樣來表示：

class BankAccount {
public:
  virtual void creditInterest() {}

  

};

class SavingsAccount: public BankAccount {  };
class CheckingAccount: public BankAccount {  };
list<BankAccount*> allAccounts;
// 看啊，沒有轉換!
for (list<BankAccount*>::iterator p = allAccounts.begin();
     p != allAccounts.end();
     ++p) {

  (*p)->creditInterest();

}

要注意的是，虛函數BankAccount::creditInterest提供一個了空的缺省實現。這可以很方便地表示，它的行為在缺省情況下是一個空操作；但這也會給它本身帶來難以預見的問題。想知道內幕，以及如何消除這一危險，請參考條款36。還要注意的是，creditInterest是一個（隱式的）內聯函數，這本身沒什么問題；但因為它同時又是一個虛函數，內聯指令就有可能被忽略。條款33解釋了為什么。

正如上面已經看到的，"向下轉換" 可以通過幾種方法來消除。最好的方法是將這種轉換用虛函數調用來代替，同時，它可能對有些類不適用，所以要使這些類的每個虛函數成為一個空操作。第二個方法是加強類型約束，使得指針的聲明類型和你所知道的真的指針類型之間沒有出入。為了消除向下轉換，無論費多大工夫都是值得的，因為向下轉換難看、容易導致錯誤，而且使得代碼難于理解、升級和維護（參見條款M32）。

至此，我所說的都是事實；但，不是全部事實。有些情況下，真的不得不執行向下轉換。

例如，假設還是面臨本條款開始的那種情況，即，allAccounts保存BankAccount指針，creditInterest只是為SavingsAccount對象定義，要寫一個循環來為每個帳戶計算利息。進一步假設，你不能改動這些類；你不能改變BankAccount，SavingsAccount或allAccounts的定義。（如果它們在某個只讀的庫中定義，就會出現這種情況）如果是這樣的話，你就只有使用向下轉換了，無論你認為這個辦法有多丑陋。

盡管如此，還是有比上面那種原始轉換更好的辦法。這種方法稱為 "安全的向下轉換"，它通過C++的dynamic_cast運算符（參見條款M2）來實現。當對一個指針使用dynamic_cast時，先嘗試轉換，如果成功（即，指針的動態類型(見條款38)和正被轉換的類型一致），就返回新類型的合法指針；如果dynamic_cast失敗，返回空指針。

下面就是加上了 "安全向下轉換" 的例子：

class BankAccount {  };          // 和本條款開始時一樣

class SavingsAccount:               // 同上
  public BankAccount {  };

class CheckingAccount:              // 同上
  public BankAccount {  };

list<BankAccount*> allAccounts;     // 看起來應該熟悉些了吧

void error(const string& msg);      // 出錯處理函數;
                                    // 見下文

// 嗯，至少轉換很安全
for (list<BankAccount*>::iterator p = allAccounts.begin();
     p != allAccounts.end();
     ++p) {

  // 嘗試將*p安全轉換為SavingsAccount*；
  // psa的定義信息見下文
  if (SavingsAccount *psa =
        dynamic_cast<SavingsAccount*>(*p)) {
    psa->creditInterest();
  }

  // 嘗試將它安全轉換為CheckingAccount
  else if (CheckingAccount *pca =
             dynamic_cast<CheckingAccount*>(*p)) {
    pca->creditInterest();
  }

  // 未知的帳戶類型
  else {
    error("Unknown account type!");
  }
}

這種方法遠不夠理想，但至少可以檢測到轉換失敗，而用dynamic_cast是無法做到的。但要注意，對所有轉換都失敗的情況也要檢查。這正是上面代碼中最后一個else語句的用意所在。采用虛函數，就不必進行這樣的檢查，因為每個虛函數調用必然都會被解析為某個函數。然而，一旦打算進行轉換，這一切好處都化為烏有。例如，如果某個人在類層次結構中增加了一種新類型的帳戶，但又忘了更新上面的代碼，所有對它的轉換就會失敗。所以，處理這種可能發生的情況十分重要。大部分情況下，并非所有的轉換都會失?。坏牵坏┰试S轉換，再好的程序員也會碰上麻煩。

上面if語句的條件部分，有些看上去象變量定義的東西，看到它你是不是慌張地擦了擦眼鏡？如果真這樣，別擔心，你沒看錯。這種定義變量的方法是和dynamic_cast同時增加到C++語言中的。這一特性使得寫出的代碼更簡潔，因為對psa或pca來說，它們只有在被dynamic_cast成功初始化的情況下，才會真正被用到；使用新的語法，就不必在（包含轉換的）條件語句外定義這些變量。（條款32解釋了為什么通常要避免多余的變量定義）如果編譯器尚不支持這種定義變量的新方法，可以按老方法來做：

for (list<BankAccount*>::iterator p = allAccounts.begin();
     p != allAccounts.end();
     ++p) {

  SavingsAccount *psa;        // 傳統定義
  CheckingAccount *pca;       // 傳統定義

  if (psa = dynamic_cast<SavingsAccount*>(*p)) {
    psa->creditInterest();
  }

  else if (pca = dynamic_cast<CheckingAccount*>(*p)) {
    pca->creditInterest();
  }

  else {
    error("Unknown account type!");
  }
}

當然，從處理事情的重要性來說，把psa和pca這樣的變量放在哪兒定義并不十分重要。重要之處在于：用if-then-else風格的編程來進行向下轉換比用虛函數要遜色得多，應該將這種方法保留到萬不得已的情況下使用。運氣好的話，你的程序世界里將永遠看不到這樣悲慘荒涼的景象。

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=8503

posted on 2007-08-30 01:44 楊粼波 閱讀(217) 評論(2)  編輯 收藏 引用