曾子曰：吾日三省吾身——為人謀而不忠乎?與朋友交而不信乎?傳不習(xí)乎?

引言

上一篇我們談到了在游戲引擎，或者在程序和高級編程語言中，設(shè)計一個統(tǒng)一對象模型得到的好處，和要付出的代價，以及在UE里是怎么對之盡量降低規(guī)避的。那么從本篇開始，我們就開始談?wù)勅绾伍_始構(gòu)建這么一個對象模型，并在此之上逐漸擴(kuò)展以適應(yīng)引擎的各種功能需求的。

眾所周知，一般游戲引擎最底層面對的都是操作系統(tǒng)API，硬件SDK，所能借助到的工具也往往只有C++本身。所以考慮從原生的C++基礎(chǔ)上，搭建對象系統(tǒng)，往往得從頭開始造輪子，最底層也是最核心的機(jī)制當(dāng)然必須得掌控在自己的手中，以后升級改善增加功能也才能不受限制。

那么，從頭開始的話，Object系統(tǒng)有那么多功能：GC，反射，序列化，編輯器支持……應(yīng)該從哪一個開始？哪一個是必需的？GC不是，因為大不了我可以直接new/delete或者智能指針引用技術(shù)，畢竟別的很多引擎也都是這么干的。序列化也不是，大不了每個子類里手寫數(shù)據(jù)排布，麻煩是麻煩，但是功能上也是可以實現(xiàn)的。編輯器支持，默認(rèn)類對象，統(tǒng)計等都是之后額外附加的功能了。那你說反射為何是必需的？大多數(shù)游戲引擎用的C++沒有反射，不也都用得好好的？確實也如此，不利用反射的那些功能，不動態(tài)根據(jù)類型創(chuàng)建對象，不遍歷屬性成員，不根據(jù)名字調(diào)用函數(shù)，大不了手寫繞一下，沒有過不去的坎。但是既然上文已經(jīng)論述了一個統(tǒng)一Object模型的好處，那么如果在Object身上不加上反射，無疑就像是砍掉了Object的一雙翅膀，讓它只能在地上行走，而不能在更寬闊空間內(nèi)發(fā)揮威力。還有另一個方面的考慮是，反射作為底層的系統(tǒng)，如果實現(xiàn)完善了，也可以大大裨益其他系統(tǒng)的實現(xiàn)，比如有了反射，實現(xiàn)序列化起來就很方便了；有沒有反射，也關(guān)系到GC實現(xiàn)時的方案選擇，完全是兩種套路。簡單舉個例，反射里對每個object有個class對象保存信息，所以理論上class身上就可以保存所有該類型的object指針引用，這個信息GC就可以利用起來實現(xiàn)一些功能；而沒有這個class對象的話，GC的實現(xiàn)就得走別的方案路子了。所以說是先實現(xiàn)反射，有了一個更加扎實的對象系統(tǒng)基礎(chǔ)后，再在此之上實現(xiàn)GC才更加的明智。

類型系統(tǒng)

雖然之上一直用反射的術(shù)語來描述我們熟知的那一套運(yùn)行時得到類型信息的系統(tǒng)，動態(tài)創(chuàng)建類對象等，但是其實“反射”只是在“類型系統(tǒng)”實現(xiàn)之后的附加功能，人們往往都太過注重最后表露的強(qiáng)大功能，而把樸實的本質(zhì)支撐給忘記了。想想看，如果我實現(xiàn)了class類用來