業(yè)務(wù)邏輯中，很多邏輯上不同類型的東西，到了編程語言中，時(shí)常會(huì)退化成一種類型。一個(gè)最簡單的例子就是貨幣。通常在我們編程時(shí)，采用一種類型，如double（有些系統(tǒng)中有專門的Currency類型，為了簡便起見，這里使用double），來表示貨幣。
但是，隨之而來的就是幣種的問題。不同的幣種間存在換算，也就是匯率的問題。比如我們有RMB和USD兩種貨幣，分別表示人民幣和美元。盡管都是貨幣（在代碼中有相同的類型），我們卻不能對(duì)他們直接賦值：
double rmb_;
double usd_=100;
rmb_=usd_; //絕對(duì)不行，100美元可相當(dāng)于768元人民幣，盡管人民幣在升值
必須進(jìn)行匯率換算：
rmb_=usd_*e_rate;
e_rate就是匯率。這個(gè)誰都清楚。在邏輯上，100美元和768元人民幣是等價(jià)的（假設(shè)今天的匯率是7.68），是可以兌換的。但在軟件中，我們不能簡單的賦值了事，必須做換算。現(xiàn)在我們希望用代碼直接表現(xiàn)邏輯上的意義，也就是用賦值操作：=，實(shí)現(xiàn)貨幣間的換算，該怎么做呢？啊對(duì)，沒錯(cuò)，操作符重載。
我們可以重載operator=操作符，使其具備匯率換算的功能。（或許有人會(huì)提出異議，改變一個(gè)操作符已有的語義，是否違背大師們的教誨。但我個(gè)人認(rèn)為，語義應(yīng)當(dāng)遵從業(yè)務(wù)邏輯，既然按照邏輯含義進(jìn)行重載，不應(yīng)該引發(fā)什么糾紛。否則還需要重載干嗎？）但問題是，重載依賴于不同的類型，double operator=(double)的操作符定義是默認(rèn)的，已經(jīng)存在，無法以相同形式重載。再說，即便是可以，復(fù)制對(duì)象和被賦值對(duì)象的類型相同，如何區(qū)分兩種類型的轉(zhuǎn)換呢？
很明顯，我們需要新的類型。typedef肯定是沒指望的，因?yàn)樗鼉H僅為一個(gè)類型起別名，并沒有產(chǎn)生新的類型。所以，我們只能求助于類。我們可以以如下方式定義各種不同的貨幣類：
class RMB
{
public:
double _val;
};
class USD
{
public:
double _val;
};
…
這樣，便可以針對(duì)不同貨幣重載operator=：
class RMB
{
public:
RMB operator=(const RMB& v) {
_val=v._val;
}
RMB operator=(const USD& v) {
_val=v._val*e_rate; //貨幣換算
}
public:
double _val;
};
class USD
{
public:
USD operator=(const USD& v) {
_val=v._val;
}
USD operator=(const RMB & v) {
_val=v._val/e_rate; //貨幣換算
}
public:
double _val;
};
這樣，我們便可以對(duì)兩種貨幣賦值了：
RMB rmb_;
USD usd_;
rmb_=usd_; //帶貨幣換算的賦值操作
根據(jù)這個(gè)方法，我們一直往下推，可以構(gòu)造出各種各樣的貨幣，并且定義它們之間的轉(zhuǎn)換：
class UKP //英鎊
{…}
class JPD //日元
{…}
…
不過有個(gè)問題，如果有10中貨幣，我們必須定義100個(gè)operator=的重載，而且都是些重復(fù)代碼。這樣太蠢了。得采用更好的方法才能實(shí)現(xiàn)我們的理想。注意觀察，每個(gè)貨幣類的代碼都符合同一種模式，有很強(qiáng)的規(guī)律性。看出來了吧，這種情況非常適合使用C++的超級(jí)武器——模板。沒錯(cuò)，說做就做：
template<int CurrType>
class Currency
{
public:
double _val;
};
注意看，這里非常規(guī)地使用了模板的一個(gè)特性：非類型模板參數(shù)，就是那個(gè)int CurrType。模板參數(shù)通常都是一個(gè)類型，比如int什么的。但也可以是一個(gè)非類型的模板參數(shù)，就象這里的CurrType。傳統(tǒng)上，非類型模板參數(shù)用于傳遞一個(gè)靜態(tài)的值，用來構(gòu)造模板類。但在這里，這個(gè)模板參數(shù)并沒有被模板使用，也永遠(yuǎn)不會(huì)被使用。這個(gè)模板參數(shù)的作用就是“制造類型”：
typedef Currency<0> RMB; //人民幣
typedef Currency<1> USD; //美元
typedef Currency<2> UKP; //英鎊
typedef Currency<3> JPD; //日元
…
typedef本身不會(huì)產(chǎn)生新的類型，但是這里Currency<n>已經(jīng)是完全不同的類型了。當(dāng)一個(gè)模板被實(shí)例化成一個(gè)類的時(shí)候，只要模板參數(shù)的實(shí)參有所不同，便是一個(gè)不同的類型。我們利用了模板的這個(gè)特性，憑空制造出任意多個(gè)結(jié)構(gòu)完全相同，但卻是完全獨(dú)立的類型。
好，下一步，便是重載operator=操作符。當(dāng)然不能再做為每一對(duì)貨幣類型重載operator=的蠢事了。用一個(gè)成員函數(shù)模板就可以解決問題：
double e_rate[10][10]; //匯率表
template<int CurrType>
class Currency
{
public:
template<int ct2>
Currency<CurrType>& operator=(count Currency<ct2>& v) {
_val=v._val * e_rate[ct2][CurrType]; //找出匯率表中相應(yīng)的匯率，
// 計(jì)算并賦值
}
public:
double _val;
};
操作符operator=的代碼中，賦值對(duì)象v的值乘上一個(gè)匯率，這個(gè)匯率存放在匯率表中，通過模板參數(shù)CurrType和ct2檢索（當(dāng)然匯率表得足夠大）。這樣，我們便可以隨意地賦值，而無須關(guān)心貨幣轉(zhuǎn)換的問題了：
///初始化匯率表
e_rate[0][0]=1;
e_rate[1][0]=7.68;
…
//使用貨幣
USD usd_;
UKP ukp_;
JPD jpd_;
jpd_=usd_=ukp=rmb_; //成功！一切順心。
需要說明的是，匯率表并沒有在聲明時(shí)就初始化，是考慮到匯率經(jīng)常變動(dòng)，不應(yīng)當(dāng)作為常量寫死在代碼中。更進(jìn)一步可以使用一個(gè)類封裝成可變大小的匯率表，甚至可以用某個(gè)文件或數(shù)據(jù)庫對(duì)其初始化。
問題當(dāng)然還有，貨幣是要參與運(yùn)算的，否則沒有什么用處。所以，我們還得使這些貨幣具備基本的計(jì)算能力。貨幣的計(jì)算，根據(jù)業(yè)務(wù)邏輯大致應(yīng)具備以下能力：
1. +、-：兩種貨幣的加法和減法，允許不同種貨幣參與計(jì)算，必須考慮轉(zhuǎn)換操作，返回做操作數(shù)類型；
2. *、/：貨幣乘上或除以一個(gè)標(biāo)量值，這里設(shè)定為double。但兩種貨幣不能相乘或相除。
3. ==、!=：比較兩種貨幣，允許不同種貨幣參與比較，但必須考慮轉(zhuǎn)換操作。
還有其他的操作，暫不做考慮，畢竟這里的目的不是開發(fā)一個(gè)完整的貨幣系統(tǒng)。為了編碼上的方便，這里同時(shí)還定義了四則運(yùn)算的賦值版本：+=、-=、*=、/=。為了節(jié)省篇幅，這里只展示+、*和==的代碼，其他代碼類推：
template<int ty, int tp>
inline bool operator==(currency<ty>& c1, const currency<tp>& c2) {
return c1._val==c2._val*curr_rate[tp][ty];
}
template<int ty, int tp>
inline currency<ty>& operator+=(currency<ty>& c1, const currency<tp>& c2) {
c1._val+=c2._val*curr_rate[tp][ty];
return c1;
}
template<int ty, int tp>
inline currency<ty> operator+(currency<ty>& c1, const currency<tp>& c2) {
currency<ty> t(c1);
t+=c2;
return t;
}
請(qǐng)注意==和+操作符中的的貨幣轉(zhuǎn)換運(yùn)算，每次都是將第二操作數(shù)貨幣轉(zhuǎn)換成第一操作數(shù)貨幣后再進(jìn)行運(yùn)算操作。第一參數(shù)和第二參數(shù)的類型不同，因此允許不同貨幣進(jìn)行計(jì)算。這可以進(jìn)一步簡化代碼，完全以邏輯的方式編程。
template<int ty>
inline currency<ty>& operator*=(currency<ty>& c1, const double q) {
c1._val*=q;
return c1;
}
template<int ty>
inline currency<ty> operator*(currency<ty>& c1, const double q) {
currency<T, ty> t(c1);
t*=q;
return t;
}
template<int ty>
inline currency<ty>& operator*=(const double q，currency<ty>& c1) {
return operator*=(c1, q);
}
template<int ty>
inline currency<ty> operator*(const double q，currency<ty>& c1) {
return operator*(c1, q);
}
…
*操作符的參數(shù)只有一個(gè)是貨幣類型，另一個(gè)是double類型，表示數(shù)量。只有貨幣乘上數(shù)量才有意義，不是嗎？*操作符包括兩個(gè)版本，一個(gè)貨幣在前，數(shù)量在后；另一個(gè)數(shù)量在前，貨幣在后。為的是適應(yīng)rmb_*1.4和1.4*rmb_兩種不同的寫法，算法是完全一樣的。
現(xiàn)在，貨幣可以運(yùn)算了：
usd_=usd_*3; //同種貨幣運(yùn)算
ukp_=rmb_*2.5; ///計(jì)算後直接賦值給另一種貨幣
jpd_=ukp_=rmb_+usd_; ///同上，但有四種貨幣參與運(yùn)算
現(xiàn)在，貨幣運(yùn)算非常方便了，不需要考慮貨幣種類，貨幣的轉(zhuǎn)換是自動(dòng)的，無需額外代碼。在簡化代碼的同時(shí)，也提供了操作上的約束，比如：
ukp_=rmb_*usd_; ///編譯錯(cuò)誤。貨幣乘上另一種貨幣無意義！！！
這句代碼會(huì)引發(fā)編譯錯(cuò)誤，因?yàn)槲覀儧]有為兩種貨幣相乘提供*的重載。很明顯，一種貨幣與另一種貨幣相乘是根本沒有意義的。這里通過靜態(tài)的重載類型檢查，對(duì)施加在貨幣上的運(yùn)算做出約束。促使違背邏輯的代碼在第一時(shí)間被攔截，避免出現(xiàn)運(yùn)行時(shí)錯(cuò)誤。要知道，兩種貨幣相乘，賦給另一個(gè)貨幣的錯(cuò)誤是非常隱蔽的，只有盤庫或結(jié)賬的時(shí)候才會(huì)發(fā)現(xiàn)。
很好，這里我們利用了C++模板的一些特殊機(jī)制，以及操作符模板、操作符重載等技術(shù)，開發(fā)一個(gè)貨幣系統(tǒng)。這個(gè)系統(tǒng)可以用最簡潔的語句實(shí)現(xiàn)各種貨幣的計(jì)算和轉(zhuǎn)換功能。同時(shí)，還利用重載機(jī)制的強(qiáng)類型特性，提供了符合業(yè)務(wù)邏輯的操作約束。
貨幣運(yùn)算只是一個(gè)簡單的案例，但相關(guān)的技術(shù)可以進(jìn)一步推廣到更復(fù)雜的領(lǐng)域中。而且業(yè)務(wù)越復(fù)雜，所得到的收益越多。因此，充分理解并運(yùn)用C++所帶來的泛型編程功能，可以大大簡化軟件的開發(fā)、減少代碼的錯(cuò)誤，降低開發(fā)的成本。
這種技術(shù)適合用在一些邏輯上存在差異，但在物理上具備相同特征的實(shí)體上。一方面使這些實(shí)體在代碼中強(qiáng)類型化，以獲得重載和類型檢測能力。由于代碼中邏輯實(shí)體的對(duì)應(yīng)類型強(qiáng)類型化，是我們可以通過重載和靜態(tài)類型檢測等技術(shù)手段，實(shí)現(xiàn)僅使用語言提供的要素，在代碼中直接構(gòu)造業(yè)務(wù)模型的能力。但手工對(duì)每一個(gè)邏輯實(shí)體進(jìn)行強(qiáng)類型化，是費(fèi)力的和瑣碎的，并且存在著大量的重復(fù)勞動(dòng)。此時(shí)，我們可以利用模板的抽象能力，反過來利用邏輯實(shí)體在物理上的共同特性，一次性構(gòu)建抽象的模板，并利用模板實(shí)例化的一些特性，很方便地構(gòu)造新的類型（僅僅一個(gè)typedef）。
這種技術(shù)進(jìn)一步擴(kuò)展后，可以有更高級(jí)的應(yīng)用。一個(gè)經(jīng)典的范例就是實(shí)現(xiàn)編譯期的量綱分析。在Template Meta-programming一書中，對(duì)此有詳細(xì)的講解。
================================================================================================
作為一個(gè)好事者，我希望能夠給我周邊的人講解這種技術(shù)。他們對(duì)C++很不熟悉，但熟悉C#。于是，我打算把這種技術(shù)移植到C#中，以便於講解。說做就做。
我建了一個(gè)C#項(xiàng)目，把代碼拷貝過去，然后著手修改，這樣可以省些事。我立刻便遇到了問題。C#有泛型，相當(dāng)于模板，但不支持非類型泛型參數(shù)，即int CurrType，只允許用一個(gè)類型作為泛型參數(shù)。這樣我們就不能使用C++中耍的手法了（typedef currency<n>）。退而求其次，直接用類實(shí)現(xiàn)貨幣類型：
class RMB
{
public double _val;
}
class USD
{
public double _val;
}
…
這樣太繁瑣了，很多重復(fù)。我們可以用一個(gè)基類封裝_val，貨幣類從基類上繼承獲得：
class CurrBase
{
public double _val;
}
class RMB : CurrBase
{
}
class USD : CurrBase
{
}
…
貨幣類都是空的，它們的存在只是為了創(chuàng)建一個(gè)新的類型。
現(xiàn)在處理貨幣轉(zhuǎn)換問題。C#不能重載operator=，所以只能使用一個(gè)helper函數(shù)泛型asign代替：
class utility
{
public static void asign<T1, T2>(T1 c1, T2 c2)
where T1 : CurrBase
where T2 : CurrBase
{
c1._val = c2._val * utility.e_rate[c2.CurID(),c1.CurID()];
}
}
這個(gè)asign函數(shù)是個(gè)泛型，泛型參數(shù)分別代表了兩個(gè)操作數(shù)，函數(shù)中執(zhí)行了貨幣轉(zhuǎn)換。為了能夠在匯率表中檢索到相應(yīng)的匯率，我們必須為基類和貨幣類定義抽象函數(shù)：
public abstract class CurrBase
{
public double _val=0;
public abstract int CurID();
}
public class RMB : CurrBase
{
public override int CurID()
{
return 0;
}
}
…
基類中聲明了CurID()抽象方法，并在貨幣類中定義。這樣，便可以用統(tǒng)一的方式進(jìn)行貨幣轉(zhuǎn)換了：
asign(rmb_, usd_);
還行，盡管不那么漂亮，但也還算實(shí)用。不過，當(dāng)我多看了幾眼代碼后，便發(fā)現(xiàn)這里根本沒有必要使用泛型。完全可以利用OOP的多態(tài)實(shí)現(xiàn)同樣的功能：
public static void asign(CurrBase c1, CurrBase c2)
{
c1._val = c2._val * utility.e_rate[c2.CurID(),c1.CurID()];
}
不過也沒關(guān)系，使用方式還沒有變，代碼反而更簡單了。使用泛型畢竟不是我們的根本目的，對(duì)吧？
現(xiàn)在輪到運(yùn)算符了。不過我不知該把泛型運(yùn)算符定義在哪里。按C#文檔里的要求，運(yùn)算符必須是類的static成員。但我的泛型運(yùn)算符是針對(duì)許多個(gè)貨幣類的，定義在任何一個(gè)中，對(duì)其他類似乎不太公平。于是，我決定嘗試將其定義在基類里：
public abstract class CurrBase
{
…
public static CurrBase operator+<T1, T2>(T1 c1, T2 c2)
where T1 : CurrBase
where T2 : CurrBase
{
…
}
}
編譯器立刻還我以顏色：操作符根本不能是泛型！好吧，不能就不能吧，繼續(xù)退而求其次，用OOP：
public abstract class CurrBase
{
…
public static CurrBase operator+(CurrBase c1, CurrBase c2)
{
…
}
}
不過，這次讓步讓得有點(diǎn)離譜。當(dāng)我寫下這樣的代碼時(shí)，編譯器居然不認(rèn)賬：
rmb_=rmb_+usd_;
錯(cuò)誤信息是：錯(cuò)誤 CS0266: 無法將類型“st_in_cs.CurrBase”隱式轉(zhuǎn)換為“st_in_cs.RMB”。存在一個(gè)顯式轉(zhuǎn)換(是否缺少強(qiáng)制轉(zhuǎn)換?)。
我非得采用強(qiáng)制類型轉(zhuǎn)換，才能過關(guān)：
rmb_=(RMB)(rmb_+usd_);
太夸張了，這樣肯定不行。于是，我被迫在每個(gè)貨幣類中定義operator+：
class RMB : CurrBase
{
…
public RMB operator+(RMB c1, USD c2)
{
…
}
public RMB operator+(RMB c1, UKP c2)
{
…
}
…
}
這可不得了，我必須為每對(duì)貨幣類定義一個(gè)+操作符，+操作符的總數(shù)將會(huì)是貨幣類數(shù)量的平方！其他的操作符每個(gè)都是貨幣類數(shù)的平方。我可受不了！
好在，可愛的OOP為我們提供了一根稻草，使得每個(gè)貨幣類的每個(gè)操作符只需定義一個(gè)：
class RMB : CurrBase
{
…
public RMB operator+(RMB c1, CurrBase c2)
{
…
}
…
}
這樣，任何貨幣類都可以作為第二操作數(shù)參與運(yùn)算，而操作符只需定義一個(gè)。這樣的工作量，對(duì)于一個(gè)逆來順受的程序員而言，還是可以接受的。很好，代碼不出錯(cuò)了：
rmb_=rmb_+usd_;
但當(dāng)我寫下如下代碼時(shí)，編譯器又開始抱怨了：
ukp_ = rmb_ + usd_;
還是要求顯示轉(zhuǎn)換，除非我們?yōu)閁KP定義隱式類型轉(zhuǎn)換操作符：
class UKP
{
…
public static implicit operator UKP(RMB v)
{
…
}
…
}
光有RMB的不行啊，還得有USD的、JPD…。不過這樣的話，我們必須為每一個(gè)貨幣類定義所有其它貨幣類的類型轉(zhuǎn)換操作符。又是一個(gè)組合爆炸。到這里，我已經(jīng)黔驢技窮了。誰讓C#不支持=操作符重載和操作符模板化呢。沒辦法，只能忍著點(diǎn)了。
不過，如果我們能夠降低點(diǎn)要求，事情還是有轉(zhuǎn)機(jī)的。如果我們不通過操作符，而是采用static成員方法，進(jìn)行貨幣的運(yùn)算的話，就可以省去很多代碼了：
public class utility
{
public static T1 asign<T1, T2>(T1 c1, T2 c2)
where T1 : CurrBase, new()
where T2 : CurrBase
{
c1._val = c2._val * utility.curr_rate[c2.CurID(),c1.CurID()];
return c1;
}
public static T1 add<T1, T2>(T1 c1, T2 c2)
where T1 : CurrBase, new()
where T2 : CurrBase
{
T1 t=new T1();
t._val=c1._val + c2._val *
utility.curr_rate[c2.CurID(),c1.CurID()];
return t;
}
…
}
這里，我還是使用了泛型，因?yàn)檫@些函數(shù)需要返回一個(gè)值，只有使用泛型，才能返回一個(gè)明確的類型，以避免強(qiáng)制轉(zhuǎn)換的要求。于是，賦值和計(jì)算的代碼就成了：
asign(jpd_, asign(ukp_, add(rmb_, usd_)));//也就是jpd_=ukp_=rmb_+usd_
的確是難看了點(diǎn)，但是為了能夠少寫點(diǎn)代碼，這也只能將就了。
好了，我盡了最大的努力，試圖在C#中實(shí)現(xiàn)強(qiáng)類型、可計(jì)算的貨幣系統(tǒng)。盡管最終我可以在C#中開發(fā)出一組與C++具有相同效果的貨幣類（除了賦值操作以外），但需要我編寫大量的代碼，實(shí)現(xiàn)各種計(jì)算操作，以及貨幣類之間的類型轉(zhuǎn)換操作（組合爆炸）。相比C++中總共200來行代碼，的確復(fù)雜、臃腫得多。
我并不希望把這篇文章寫成“C++ vs C#”，（盡管我很高興看到C++比C#強(qiáng)?）。我希望通過對(duì)這樣一個(gè)代碼優(yōu)化任務(wù)，顯示不同技術(shù)運(yùn)用產(chǎn)生的結(jié)果。同時(shí)，也可以通過這兩種實(shí)現(xiàn)嘗試的對(duì)比，了解泛型編程的作用，以及泛型編程對(duì)語言提出的要求。
毋庸置疑，C++采用了純粹的泛型編程，因此可以對(duì)問題進(jìn)行高度抽象。并利用問題所提供的每一點(diǎn)有助于抽象的信息，以最簡的形式對(duì)問題建模。而作為以O(shè)OP為核心的語言C#，對(duì)泛型的支持很弱。更重要的是，C#的泛型對(duì)泛型參數(shù)的運(yùn)用嚴(yán)重依賴於泛型參數(shù)的約束（where）。如果沒有where，C#將泛型參數(shù)作為Object類型處理，此時(shí)泛型參數(shù)沒有意義（我無法訪問該類型的成員）。如果有了where，C#要求泛型參數(shù)必須同where中指定的類型有繼承關(guān)系（如asign中的T1必須是CurrBase的繼承類）。而泛型函數(shù)中對(duì)泛型參數(shù)的使用也局限在約束類型（即CurrBase）上。于是，我們可以直接用以基類（CurrBase）為參數(shù)的asign函數(shù)代替泛型版本的asign。由于C#對(duì)泛型參數(shù)的繼承性要求，使得泛型被困住了手腳，無法發(fā)揮應(yīng)用的作用。正由于這些問題，C++才采用了現(xiàn)在模板的形式，而沒有采用同C#一樣的泛型模式。
或許有人會(huì)說，既然OOP能解決問題（asign最初不需要泛型也行，但最終還需要泛型來控制返回值的類型），為什么還要GP呢？
對(duì)于這個(gè)問題，前面也給出了答案。由于C#的泛型不支持非類型泛型參數(shù)，因此迫使我們使用傳統(tǒng)OOP的手段：利用基類實(shí)現(xiàn)貨幣類的實(shí)現(xiàn)，定義貨幣類來創(chuàng)建新類型，使貨幣強(qiáng)類型化，利用虛函數(shù)提供貨幣獨(dú)有信息。僅這一層面，OOP方式已經(jīng)大大不如GP方式了，GP僅定義了一個(gè)模板，所有的貨幣類型都是通過typedef一句語句產(chǎn)生，無需更多的代碼。而OOP方式要求必須為每一個(gè)貨幣編寫一個(gè)類，代碼量明顯多于GP方式。
此后，C++通過重載一組操作符模板，實(shí)現(xiàn)貨幣的運(yùn)算。而貨幣模板以及生成貨幣類型的typedef都無須任何改變。而在C#中，由于不支持泛型操作符，被迫定義大量的特定于類型的操作符。所有運(yùn)算操作符，在每個(gè)貨幣類中都必須重載一次。而轉(zhuǎn)型操作符，則必須在每個(gè)貨幣類中重載n-1次。
換句話說，有n種貨幣，有m個(gè)操作符（包括轉(zhuǎn)型操作符），那么就需要定義n+1個(gè)類（包括基類），n×m+n×(n-1)個(gè)操作符。假設(shè)n=10，m=10，那么總共需要11個(gè)類定義，190個(gè)操作符重載！如果每個(gè)類定義需要20行代碼，而每個(gè)操作符重載需要5行代碼，那么總共需要1170行代碼。如果貨幣數(shù)量增加，總的代碼數(shù)將以幾何級(jí)數(shù)的方式增長。
上面的計(jì)算表明，盡管OOP可以解決問題，實(shí)現(xiàn)我們的目標(biāo)，但所帶來的開發(fā)量和維護(hù)量卻是難以承受的。而且，OOP的方式擴(kuò)展非常困難，隨著系統(tǒng)規(guī)模的擴(kuò)大，擴(kuò)展將越來越困難。所有這些都表明一點(diǎn)，盡管OOP是軟件工程的明星，但在實(shí)際情況下，很多地方存在著OOP無法解決或難以解決的問題。這也就是為什么業(yè)界的先鋒人物不斷拓展和強(qiáng)化泛型編程的原因。