類的膨脹(Bloating)指的是類中成員過多，甚至出現無序增加的情況。過大的類，會使得複雜度急劇增加，維護會變得更爲困難。所以需要控制類的增長。本文總結了一下，簡單介紹四種解決的方式，我故意用四個來講，主要爲了介紹最後一種方式。
(以下將需要避免膨脹類稱爲目標類，即類圖中的Car類。)
友元類
這個是最爲原始的思路。成員變量仍然要增加，以友元類可以訪問類的私有成員的能力來減少一些方法。
這種方式的壞處是將所有的調用者加入友元類並不現實。它的情形類似:
class Car {
……
friend class Driver;
friend class Sales;
friend class Passenger;
……
}
Helper Class
如果將新增加的成員放到一個Helper Class中，這樣目標類提供新的方法供外部使用，內部再調用Helper的實現。這種方式下方法仍然要增加。
而另一種方法，也是比較常用的。在目標類中提供一個函數將Helper class開放出去，可以供需要使用它的類直接使用。
【這裏Helper class也可以是目標類的友元類。】
Visitor模式
有時我們只是要利用一個類現有的方法來實現不同的算法。就可以使用觀察者模式來實現。
將需要新增加的算法放到Vistor中，而不是目標類中。如果有需要也可以將Visitor設爲目標的友元類。
這個方案與Helper Class的最大差異在於客戶端可能需要不同版本的算法實現，而且是由客戶端指定。
綁定形式的Helper Class
無論是簡單的Helper Class，還是Visitor模式，Helper及Visitor的生命週期管理都需要由目標類及客戶類管理。另外Helper Class不能將不同類別的方法和成員變量區分出來 (不同類別代表了不同職責，我們可不要God Class)，而Visitor不適用於需要增加成員變量的需求。
在Chromium中提供了一個類似Binding的機制。原理上就是將我要增加的數據和方法按不同的類別封裝成一個個類，然後以自身指定的內容作爲key綁定到目標類上。需要使用時使用一個靜態方法，傳入之前指定的key就可以取到對應類，然後操作。
本質上這也是一個Helper Class的實現，只是這個Helper完成了相關數據對象的存取操作。
結構如下:
(詳見Chromium代碼中的base::SupportsUserData。)
這時目標類不用改動一行代碼，就能增加它所持有的數據和方法了。
轉載請註明出處:http://blog.csdn.net/horkychen
