範型程式設計雜談
談範型(GP)之前, 先談一下物件導向(OO), OO強調世界是由物件組成的,物件是由方法和屬性組成的(個人感覺還應該加上事件),而物件之間又有繼承(is-a)和組合等 關係。OO很符合我們認識世界的直覺,它以封裝,繼承和多型為特性,我們在現實工作中又總結出來了OO的5大設計原則和23種設計模式。總之,OO基本上已經可以很好的解決我們現實生活中的所有問題。
那麼既然OO已經可以很好的解決我們的問題了,為什麼還要有GP?
我們先來看一下OO的缺點:
OO的多型是通過繼承自同一介面來實現的, 修改介面會導致所有派生類的修改,耦合比較緊密。
OO的多型是執行時的, 效能比較低。
OO的多型通過抽象介面實現,使用不安全,在不支援反射的語言(比如C++)中會喪失型別檢測。
用OO設計時,你只能通過抽象介面來處理不同的事物。比如你要讓Cat和Dog同時跑動,你可能會抽象出一個IAnimal介面,內部有一個Run的方法,然後讓Cat和Dog分別繼承。但是如果你想讓貓(Cat)和玩具貓(ToyCat)支援跑動,這時你抽象出IAnimal就不合適了, 你可能會抽象出ICatProperty。可以看到OO的這種繼承體系非常笨重,到後面可能會導致非常深的繼承層次(比如MFC),程式碼擴充套件和維護都很艱難。
上面OO的這些缺點在GP沒有被發現之前都不是缺點,因為我們沒有更好的解決方案,但是人們逐漸發現了GP,GP最初是在使用容器(Container)時被發現的,container<T>可以放任意型別的元素,根據元素型別,我們可以可以生成任意型別的container. 這些技術後來發展成範型程式設計和模板超程式設計。
那麼什麼是GP?
我的理解是 GP是基於concept的程式設計,我們通過concept來定義物件之間的關係。
什麼是concept?
按我的理解,concept就是我們自己定義的概念和規則。
比如說任何物件,只要可賦值,他就符合Assignable的concept:
又比如任何物件,只要可比較, 他就符合Comparable的concept:
再看一個例子:
GP的concept可以是任何我們能想到的規則,比如包含某個成員變數,或是定義某個型別, 比如下面程式碼:
甚至GP的concept可以是指明基類和派生類, 比如下面程式碼:
這些concept在不同語言中定義不一樣,在一些語言中(比如C#)我們可以通過定義來進行顯式約束,表明我們某個concept要滿足哪些條件;在有些語言中(比如C++)則沒有這顯式約束定義,我們只能通過我們程式設計時自己的邏輯來保證,當然如果某個方法要求他的物件滿足某個concept而你的物件沒有滿足 ,編譯器也是不會讓你通過的。
另外GP的concept之間本身也有某種關係, 某個concept可能繼承與另外一個concept,或者說某個concept是另外一個concept的強化,也就是滿足某個concept的物件肯定也同時滿足另外一個concept. 比如concept A包含Run方法, concept B包含Run和Eat方法,則concept B是concept A的強化,滿足concept B的物件肯定同時滿足concept A。
有些人說GP的抽象能力高於OO,這個觀點我並不認同,我感覺只是他們的抽象方式不一樣,OO是基於介面, 而GP是基於concept。OO的基於介面的抽象,在原始碼和最終執行時都能體現,原始碼中是介面,執行時是虛表,所以他們是一致的, 符合普通人的思維習慣。GP基於concept的抽象, 主要體現在原始碼中 ,只是你用來告訴編譯器你的思維方式, 在執行時他可能是一個完全不同的世界,所以比較難理解。
如果說OO的設計是抽象出介面, GP的設計就是抽象出concept, 滿足某個concept的class是一個template class(如template<typename T> class vector), 而template class的又可以例項化成某個特定的class(如vector<int>)。 所以GP可以大大減少我們原始碼的數量,但是他本身不能減小我們最終編譯的可執行檔案的大小,相反如果模板類過大,反而會造成程式碼膨脹,而OO的繼承則沒有這個問題(可參考C++模板會使程式碼膨脹嗎)。
對於在實際開發中主要用OO還是用GP的問題, 可能應人和公司而異, 最好的方式當然是OO和GP的靈活結合。有人覺得GP的程式碼不好理解,那是因為你沒有理解他的concept,比如看了《範型程式設計與STL》,你就會發現自己也可以擴充套件STL了。當然,因為C++對concept沒有約束定義機制, 而concept這個東西註釋又不好描述,所以大部分時候我們只能通過原始碼來推理,這在一定程度上也造成了GP程式碼難讀懂這種說法的流行。
那麼既然OO已經可以很好的解決我們的問題了,為什麼還要有GP?
我們先來看一下OO的缺點:
OO的多型是通過繼承自同一介面來實現的, 修改介面會導致所有派生類的修改,耦合比較緊密。
OO的多型是執行時的, 效能比較低。
OO的多型通過抽象介面實現,使用不安全,在不支援反射的語言(比如C++)中會喪失型別檢測。
用OO設計時,你只能通過抽象介面來處理不同的事物。比如你要讓Cat和Dog同時跑動,你可能會抽象出一個IAnimal介面,內部有一個Run的方法,然後讓Cat和Dog分別繼承。但是如果你想讓貓(Cat)和玩具貓(ToyCat)支援跑動,這時你抽象出IAnimal就不合適了, 你可能會抽象出ICatProperty。可以看到OO的這種繼承體系非常笨重,到後面可能會導致非常深的繼承層次(比如MFC),程式碼擴充套件和維護都很艱難。
上面OO的這些缺點在GP沒有被發現之前都不是缺點,因為我們沒有更好的解決方案,但是人們逐漸發現了GP,GP最初是在使用容器(Container)時被發現的,container<T>可以放任意型別的元素,根據元素型別,我們可以可以生成任意型別的container. 這些技術後來發展成範型程式設計和模板超程式設計。
那麼什麼是GP?
我的理解是 GP是基於concept的程式設計,我們通過concept來定義物件之間的關係。
什麼是concept?
按我的理解,concept就是我們自己定義的概念和規則。
比如說任何物件,只要可賦值,他就符合Assignable的concept:
class A {};
class B {};
void test()
{
A a1; A a2; a1 = a2;
B b1; B b2; b1 = b2;
}
上面的A和B就都符合Assignable的concept.class B {};
void test()
{
A a1; A a2; a1 = a2;
B b1; B b2; b1 = b2;
}
又比如任何物件,只要可比較, 他就符合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);
};
上面的物件C,他就符合他就符合Comparable的concept。{
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);
};
再看一個例子:
class Dog
{
public:
void run();
};
class Cat
{
public:
void run();
};
template<typename T>
void run(T& t)
{
t.run();
}
上面的Cat和Dog就都符合擁有成員函式Run這個concept.{
public:
void run();
};
class Cat
{
public:
void run();
};
template<typename T>
void run(T& t)
{
t.run();
}
GP的concept可以是任何我們能想到的規則,比如包含某個成員變數,或是定義某個型別, 比如下面程式碼:
class myTraits
{
public:
typedef int type;
type value;
};
template<typename T>
typename T::type GetValue(T& t)
{
return t.value;
}
{
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中大量應用這種concept來實現程式碼重用和模擬虛擬函式。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() {}
};
這些concept在不同語言中定義不一樣,在一些語言中(比如C#)我們可以通過定義來進行顯式約束,表明我們某個concept要滿足哪些條件;在有些語言中(比如C++)則沒有這顯式約束定義,我們只能通過我們程式設計時自己的邏輯來保證,當然如果某個方法要求他的物件滿足某個concept而你的物件沒有滿足 ,編譯器也是不會讓你通過的。
另外GP的concept之間本身也有某種關係, 某個concept可能繼承與另外一個concept,或者說某個concept是另外一個concept的強化,也就是滿足某個concept的物件肯定也同時滿足另外一個concept. 比如concept A包含Run方法, concept B包含Run和Eat方法,則concept B是concept A的強化,滿足concept B的物件肯定同時滿足concept A。
我們可以看到GP的這種基於concept的設計方式,大大降低了物件之間的耦合性,我們不再要求象OO那樣抽象出共同的介面來讓大家繼承;任何兩個看似沒有關係的物件, 只要他們滿足某個concept的約束,他們就能當作模板引數傳給GP程式碼(模板類或是模板函式)。另外,我們可以看到GP的這些型別檢測是在編譯時就完成的,他的多型是在編譯時就確定的靜多型, 效率大大高於OO的動多型。
有些人說GP的抽象能力高於OO,這個觀點我並不認同,我感覺只是他們的抽象方式不一樣,OO是基於介面, 而GP是基於concept。OO的基於介面的抽象,在原始碼和最終執行時都能體現,原始碼中是介面,執行時是虛表,所以他們是一致的, 符合普通人的思維習慣。GP基於concept的抽象, 主要體現在原始碼中 ,只是你用來告訴編譯器你的思維方式, 在執行時他可能是一個完全不同的世界,所以比較難理解。
如果說OO的設計是抽象出介面, GP的設計就是抽象出concept, 滿足某個concept的class是一個template class(如template<typename T> class vector), 而template class的又可以例項化成某個特定的class(如vector<int>)。 所以GP可以大大減少我們原始碼的數量,但是他本身不能減小我們最終編譯的可執行檔案的大小,相反如果模板類過大,反而會造成程式碼膨脹,而OO的繼承則沒有這個問題(可參考C++模板會使程式碼膨脹嗎)。
對於在實際開發中主要用OO還是用GP的問題, 可能應人和公司而異, 最好的方式當然是OO和GP的靈活結合。有人覺得GP的程式碼不好理解,那是因為你沒有理解他的concept,比如看了《範型程式設計與STL》,你就會發現自己也可以擴充套件STL了。當然,因為C++對concept沒有約束定義機制, 而concept這個東西註釋又不好描述,所以大部分時候我們只能通過原始碼來推理,這在一定程度上也造成了GP程式碼難讀懂這種說法的流行。
相關文章
- 程式設計雜談——Non-breaking space程式設計
- 函數語言程式設計雜談函數程式設計
- 雜篇:隨筆程式設計雜談錄–《隆中對》程式設計
- 設計模式雜談設計模式
- 隨筆程式設計雜談錄–《隆中對》程式設計
- 研發規範雜談
- 談談 "JS 和 設計泛型"JS泛型
- 程式設計小記-程式設計規範程式設計
- java遊戲開發雜談 - java程式設計怎麼學Java遊戲開發程式設計
- JS程式設計規範JS程式設計
- React程式設計規範React程式設計
- python程式設計規範Python程式設計
- 今日頭條:iOS 架構設計雜談iOS架構
- 雜談!設計師表達溝通策略
- 談談BEM規範(含程式碼)
- 面試必談的雜湊,.Net 程式設計師溫故而知新面試程式設計師
- 萬智牌設計雜談:重複利用(上)
- 萬智牌設計雜談:重複利用(下)
- 戲說領域驅動設計(十)——雜談
- 談談對程式設計師的管理程式設計師
- 程式碼規範淺談
- 0 程式碼量雜談
- 泛型程式設計泛型程式設計
- Go 語言程式設計規範Go程式設計
- python 程式設計規範有哪些?Python程式設計
- 程式設計命名規範(網文)程式設計
- 十、GO程式設計模式 : 泛型程式設計Go程式設計設計模式泛型
- 後端技術雜談8:OpenStack架構設計後端架構
- 程式設計師談薪指北程式設計師
- 淺談非同步程式設計非同步程式設計
- 【C++ 泛型程式設計01:模板】函式模板與類别範本C++泛型程式設計函式
- java 泛型程式設計Java泛型程式設計
- Shell程式設計規範與變數程式設計變數
- Python程式設計規範+最佳實踐Python程式設計
- 上位機程式設計編碼規範程式設計
- 微信小程式元件設計規範微信小程式元件
- 程式設計雜談:從人類與軟體系統的根本矛盾說起程式設計
- Rust中的範型程式設計-Exonum是如何從Iron轉移到Actix-webRust程式設計Web
- 物件導向程式設計和`GP`泛型程式設計物件程式設計泛型