談泛型
(GP)之前, 先談一下面向?qū)ο?OO), OO強(qiáng)調(diào)世界是由對(duì)象組成的，對(duì)象是由方法和屬性組成的(個(gè)人感覺還應(yīng)該加上事件)，而對(duì)象之間又有繼承(is-a)和組合等 關(guān)系。OO很符合我們認(rèn)識(shí)世界的直覺，它以封裝，繼承和多態(tài)為特性，我們?cè)诂F(xiàn)實(shí)工作中又總結(jié)出來了OO的5大設(shè)計(jì)原則和23種設(shè)計(jì)模式。總之，OO基本上已經(jīng)可以很好的解決我們現(xiàn)實(shí)生活中的所有問題。那么既然OO已經(jīng)可以很好的解決我們的問題了，為什么還要有GP? 我們先來看一下OO的缺點(diǎn)：OO的多態(tài)是通過繼承自同一接口來實(shí)現(xiàn)的， 修改接口會(huì)導(dǎo)致所有派生類的修改，耦合比較緊密。OO的多態(tài)是運(yùn)行時(shí)的， 性能比較低。OO的多態(tài)通過抽象接口實(shí)現(xiàn)，使用不安全，在不支持反射的語言(比如C++)中會(huì)喪失類型檢測(cè)。 用OO設(shè)計(jì)時(shí)，你只能通過抽象接口來處理不同的事物。比如你要讓Cat和Dog同時(shí)跑動(dòng)，你可能會(huì)抽象出一個(gè)IAnimal接口，內(nèi)部有一個(gè)Run的方法，然后讓Cat和Dog分別繼承。但是如果你想讓貓(Cat)和玩具貓(ToyCat)支持跑動(dòng)，這時(shí)你抽象出IAnimal就不合適了， 你可能會(huì)抽象出ICatProperty。可以看到OO的這種繼承體系非常笨重，到后面可能會(huì)導(dǎo)致非常深的繼承層次(比如MFC)，代碼擴(kuò)展和維護(hù)都很艱難。上面OO的這些缺點(diǎn)在GP沒有被發(fā)現(xiàn)之前都不是缺點(diǎn)，因?yàn)槲覀儧]有更好的解決方案，但是人們逐漸發(fā)現(xiàn)了GP，GP最初是在使用容器(Container)時(shí)被發(fā)現(xiàn)的，container<T>可以放任意類型的元素，根據(jù)元素類型，我們可以可以生成任意類型的container. 這些技術(shù)后來發(fā)展成泛型
編程和模板元編程。那么什么是GP？我的理解是 GP是基于concept的程序設(shè)計(jì)，我們通過concept來定義對(duì)象之間的關(guān)系。什么是concept？ 按我的理解，concept就是我們自己定義的概念和規(guī)則。比如說任何對(duì)象，只要可賦值，他就符合Assignable的concept:class A {};
class B {};
void test()
{
A a1; A a2; a1 = a2;
B b1; B b2; b1 = b2;
}
上面的A和B就都符合Assignable的concept.又比如任何對(duì)象，只要可比較， 他就符合Comparable的concept:class C
{
public:
bool operator < (const C& c);
bool operator > (const C& c);
bool operator == (const C& c);
bool operator != (const C& c);
bool operator <= (const C& c);
bool operator >= (const C& c);
};
上面的對(duì)象C，他就符合他就符合Comparable的concept。再看一個(gè)例子:class Dog
{
public:
void run();
};
class Cat
{
public:
void run();
};
template<typename T>
void run(T& t)
{
t.run();
}
上面的Cat和Dog就都符合擁有成員函數(shù)Run這個(gè)concept.GP的concept可以是任何我們能想到的規(guī)則，比如包含某個(gè)成員變量，或是定義某個(gè)類型， 比如下面代碼:class myTraits
{
public:
typedef int type;
type value;
};
template<typename T>
typename T::type GetValue(T& t)
{
return t.value;
}
甚至GP的concept可以是指明基類和派生類, 比如下面代碼：template<typename TDrived, typename TBase>
class CMyImpl: public TBase
{
public:
void work()
{
TDrived* p = static_cast<TDrived*>(this);
p->Hello();
}
};
class CMyBase {};
class CMyClass: public CMyImpl<CMyClass, CMyBase>
{
public:
void Hello() {}
};
ATL中大量應(yīng)用這種concept來實(shí)現(xiàn)代碼重用和模擬虛函數(shù)。這些concept在不同語言中定義不一樣，在一些語言中(比如C#)我們可以通過定義來進(jìn)行顯式約束，表明我們某個(gè)concept要滿足哪些條件；在有些語言中(比如C++)則沒有這顯式約束定義，我們只能通過我們編程時(shí)自己的邏輯來保證，當(dāng)然如果某個(gè)方法要求他的對(duì)象滿足某個(gè)concept而你的對(duì)象沒有滿足 ，編譯器也是不會(huì)讓你通過的。另外GP的concept之間本身也有某種關(guān)系， 某個(gè)concept可能繼承與另外一個(gè)concept，或者說某個(gè)concept是另外一個(gè)concept的強(qiáng)化，也就是滿足某個(gè)concept的對(duì)象肯定也同時(shí)滿足另外一個(gè)concept. 比如concept A包含Run方法， concept B包含Run和Eat方法，則concept B是concept A的強(qiáng)化，滿足concept B的對(duì)象肯定同時(shí)滿足concept A。我們可以看到GP的這種基于concept的設(shè)計(jì)方式，大大降低了對(duì)象之間的耦合性，我們不再要求象OO那樣抽象出共同的接口來讓大家繼承；任何兩個(gè)看似沒有關(guān)系的對(duì)象， 只要他們滿足某個(gè)concept的約束，他們就能當(dāng)作模板參數(shù)傳給GP代碼(模板類或是模板函數(shù))。另外，我們可以看到GP的這些類型檢測(cè)是在編譯時(shí)就完成的，他的多態(tài)是在編譯時(shí)就確定的靜多態(tài)， 效率大大高于OO的動(dòng)多態(tài)。
有些人說GP的抽象能力高于OO，這個(gè)觀點(diǎn)我并不認(rèn)同，我感覺只是他們的抽象方式不一樣，OO是基于接口， 而GP是基于concept。OO的基于接口的抽象，在源代碼和最終運(yùn)行時(shí)都能體現(xiàn)，源代碼中是接口，運(yùn)行時(shí)是虛表，所以他們是一致的， 符合普通人的思維習(xí)慣。GP基于concept的抽象， 主要體現(xiàn)在源代碼中 ，只是你用來告訴編譯器你的思維方式， 在運(yùn)行時(shí)他可能是一個(gè)完全不同的世界，所以比較難理解。如果說OO的設(shè)計(jì)是抽象出接口， GP的設(shè)計(jì)就是抽象出concept, 滿足某個(gè)concept的class是一個(gè)template class（如template<typename T> class vector）, 而template class的又可以實(shí)例化成某個(gè)特定的class(如vector<int>)。 所以GP可以大大減少我們?cè)创a的數(shù)量，但是他本身不能減小我們最終編譯的可執(zhí)行文件的大小，相反如果模板類過大，反而會(huì)造成代碼膨脹，而OO的繼承則沒有這個(gè)問題（可參考C++模板會(huì)使代碼膨脹嗎）。對(duì)于在實(shí)際開發(fā)中主要用OO還是用GP的問題， 可能應(yīng)人和公司而異, 最好的方式當(dāng)然是OO和GP的靈活結(jié)合。有人覺得GP的代碼不好理解，那是因?yàn)槟銢]有理解他的concept，比如看了《泛型
編程與STL》，你就會(huì)發(fā)現(xiàn)自己也可以擴(kuò)展STL了。當(dāng)然，因?yàn)镃++對(duì)concept沒有約束定義機(jī)制， 而concept這個(gè)東西注釋又不好描述，所以大部分時(shí)候我們只能通過源代碼來推理，這在一定程度上也造成了GP代碼難讀懂這種說法的流行。不知道大家在實(shí)際開發(fā)中GP用的多不多?
posted on 2012-11-10 14:25
Richard Wei 閱讀(3293)
評(píng)論(7) 編輯 收藏 引用 所屬分類:
STL&GP