靈感

這篇文章的靈感，來自最近Unity的知名工程師Aras Pranckevi?ius一次面向初級開發(fā)者的公開演講，演講的目的是讓他們熟悉新的“ECS”架構(gòu)的一些術(shù)語。

Aras使用了非常典型的模式，他展示了一些非常糟糕的OOP代碼，然后表示關(guān)系模型是個更好的方案（不過這里的關(guān)系模型稱為“ECS”）。我并不是要批評Aras，實際上我很喜歡他的作品，也非常贊賞他的演講！

我選擇他的演講而不是網(wǎng)上幾百篇關(guān)于ECS的其他帖子的原因是，他的演講給出了代碼，里面有個非常簡單的小“游戲”用來演示各種不同的架構(gòu)。這個小項目節(jié)省了我很多精力，可以方便我闡述自己的觀點，所以，謝謝Aras！

Aras幻燈片的鏈接：

• https://github

• 展示一些很糟糕的OOP代碼，其設(shè)計很垃圾，通常是過度使用繼承（這一條就違反了許多OOD原則）。

• 證明組合要比繼承更好（其實OOD早就這么說過）。

• 證明關(guān)系模型很適合游戲開發(fā)（只不過改名叫ECS）。

這種結(jié)構(gòu)的文章很讓我惱火，因為：

• 偷換概念。它對比的對象風(fēng)馬牛不相及，這一點很難讓人信服，雖然可能是出于無意，卻也并不能證明它提出的新架構(gòu)更好。

• 它會產(chǎn)生副作用，貶低知識，并且無意間打擊讀者去學(xué)習(xí)該領(lǐng)域長達五十多年的研究結(jié)果。關(guān)系模型第一次是在上世紀六十年代提出的。七八十年代深入研究了該模型的各個方面。新手經(jīng)常提出的問題是“這個數(shù)據(jù)應(yīng)該放到哪個類里？”而該問題的答案通常很模糊，“等你有了更多經(jīng)驗以后自然而然就知道了”。但在七十年代，這個問題深入地研究，并用通用的、正式的方式解決了，即數(shù)據(jù)庫的正規(guī)化（https://en.wikipedia.org/wiki/Database_normalization#Normal_forms）。忽略已有的研究成果把ECS當作全新的方案來展示，就等于把這些知識藏起來不告訴新手程序員。

面向?qū)ο缶幊痰臍v史也同樣悠久（實際上比關(guān)系模型還要久，它的概念從上世紀五十年代就出現(xiàn)了）！但是，直到九十年代，OO才得到人們的背景

前面說過，上世紀九十年代是OO的大爆炸時代，那個時期的“壞OOP代碼”可能是最糟糕的。如果你在那個時期學(xué)習(xí)了OOP，那么你很可能學(xué)過下面的“OOP四大支柱”：

• 抽象

• 封裝

• 多態(tài)

• 繼承

我更傾向于稱他們?yōu)椤癘OP的四大工具”而不是四大支柱。這些工具可以用來解決問題。但是，只學(xué)習(xí)工具的用法是不夠的，你必須知道什么時候應(yīng)該使用它們。

教育者只傳授工具的用法而不傳授工具的使用場景，是不負責(zé)任的表現(xiàn)。在二十一世紀初，第二波OOD思潮出現(xiàn)，工具的濫用得到了一定的抑制。

當時提出了SOLID（https://en.wikipedia.org/wiki/SOLID）思想體系來快速評價設(shè)計的質(zhì)量。注意其中的許多

• 里氏替換原則（Liskov Substitution Principle）。每個接口的實現(xiàn)都應(yīng)該100%遵循接口的要求，即任何能在接口上運行的算法都應(yīng)該能在具體的實現(xiàn)上運行。

接口隔離原則（Interface Segregation Principle ）。接口應(yīng)當盡量小，保證每一部分代碼都“只需了解”最小量的代碼，也就是說避免不必要的依賴。這一條

• 依賴倒置原則（Dependency Inversion Principle）。兩個具體的實現(xiàn)直接通信并且互相依賴的模式，可以通過將兩者之間的通信接口正規(guī)化成第三個類，將這個類作為兩者之間的接口的方式解耦合。這第三個類可以是個抽象積累，定義兩者之間需要的調(diào)用，甚至可以只是個定義兩者間傳遞數(shù)據(jù)的簡單數(shù)據(jù)結(jié)構(gòu)。

• 這一條不在SOLID中，但我認為這一條同樣重要：組合重用原則（Composite Reuse Principle）。默認情況下應(yīng)當使用組合，只有在必須時才使用繼承。

這才是我們的SOLID C++。

接下來我用三字母的簡稱來代表這些原則：SRP、OCP、LSP、ISP、DIP、CRP。

一點其他看法：

在OOD中，接口和實現(xiàn)并不對應(yīng)任何具體的OOP關(guān)鍵字。在C++中，接口通常用抽象類和虛函數(shù)建立，然后實現(xiàn)從基類繼承……但那只是實現(xiàn)接口的概念的一種方式而已。C++中能使用PIMPL（https://en.cppreference

• 上面說過，如果建立一個簡單的數(shù)據(jù)結(jié)構(gòu)負責(zé)從一個類傳遞數(shù)據(jù)到另一個類，那么該結(jié)構(gòu)就起到了接口的作用——用正式的語言來說，這叫數(shù)據(jù)定義（https://en.wikipedia.org/wiki/Data_definition_language）。

• 即使只是將一個類分成了公有和私有兩部分，那么所有公有部分中的東西都是接口，而私有部分的都是實現(xiàn)。

• 繼承實際上（至少）有兩種類型：接口繼承，實現(xiàn)繼承。

• 在C++中，接口繼承包括：利用純虛函數(shù)實現(xiàn)的抽象基類、PIMPL、條件typedef。在Java中，接口繼承用implements關(guān)鍵字表示。

• 在C++中，實現(xiàn)繼承發(fā)生在一切基類包含純虛函數(shù)以外的內(nèi)容的情況。在Java中，實現(xiàn)繼承用Extends關(guān)鍵字表示。

• OOD定義了許多關(guān)于接口繼承的規(guī)則，但實現(xiàn)繼承通常是不祥的預(yù)兆（https://en.wikipedia.org/wiki/Code_smell）。

最后，我也許應(yīng)該給出一些糟糕的OOP教育的例子，以及這種教育導(dǎo)致的糟糕代碼（以及OOP的壞名聲）。

在學(xué)習(xí)層次結(jié)構(gòu)和繼承時，你很可能學(xué)習(xí)過以下類似的例子：

• 假設(shè)我們有個學(xué)校的應(yīng)用，其中包括學(xué)生和教職工的名錄。于是我們可以用Person作為基類，然后從Person繼承出Student和Staff兩個類。

• 這完全錯了。先等一下。LSP（里氏替換原則）指出，類的層次結(jié)構(gòu)和操作它們的算法是共生（symbiotic）的。它們是一個完整程序的兩個部分。OOP是過程式編程的擴展，它的主要結(jié)構(gòu)依然是過程。所以，如果不知道Student和Staff上的算法（以及哪些算法可以用多態(tài)來簡化），那么設(shè)計類層次結(jié)構(gòu)是不負責(zé)任的。必須首先有算法和數(shù)據(jù)才能繼續(xù)。

在學(xué)習(xí)層次結(jié)構(gòu)和繼承時，你很可能學(xué)習(xí)過以下類似的例子：

假設(shè)你有個形狀的類。它的子類可以有正方形和矩形。那么，應(yīng)該是正方形is-a矩形，還是矩形is-a正方形？

這個例子其實很好地演示了實現(xiàn)繼承和接口繼承之間的區(qū)別。

如果你考慮的是實現(xiàn)繼承，那么你完全沒有考慮LSP，只不過是把繼承當做復(fù)用代碼的工具而已。從這個觀點來看，下面的定義是完全合理的：struct Square { int width; }; struct Rectangle: Square { int height; }; 正方形只有寬度，而矩形在寬度之外還有高度，所以用高度擴展正方形，就能得到矩形！

你一定猜到了，OOD認為這種設(shè)計（很可能）錯了。我說可能的原因是你還可以爭論其中暗含的接口……不過這無關(guān)緊要。

正方形的寬度和高度永遠相同，所以從正方形的接口的角度來看，我們完全可以認為它的面積是“寬度×寬度”。

如果矩形從正方形繼承，那么根據(jù)LSP，矩形必須遵守正方形接口的規(guī)則。所有能在正方形上正確工作的算法必須能在矩形上正確工作。

• 比如下面的算法：std::vector<Square*> shapes; int area = 0; for (auto s: shapes) area += s->width * s-> width; 這個算法能在正方形上正確工作（產(chǎn)生所有面積之和），但對于矩形則不能正確工作。因此，矩形違反了LSP原則。

• 如果用接口繼承的方式來思考，那么無論是正方形還是矩形，都不應(yīng)該從對方繼承。正方形和矩形的接口實際上是不同的，誰都不是誰的超集。

• 所以，OOD實際上并不鼓勵實現(xiàn)繼承。前面說過，如果你要復(fù)用代碼，OOD認為應(yīng)該使用組合！

• 所以，上面實現(xiàn)繼承的層次結(jié)構(gòu)代碼的正確版本，用C++來寫應(yīng)該是這樣：

struct Shape { virtual int area const = 0; };
struct Square : public virtual Shape { virtual int area const { return width * width; }; int width; };
struct Rectangle : private Square, public virtual Shape { virtual int area const { return width * height; }; int height; };

• public virtual相當于Java中的implements，在實現(xiàn)一個接口時使用。

• private可以讓你從基類繼承，而無需繼承它的接口。在本例中，Rectangle is-not-a Square，雖然它繼承了Square。

• 我不推薦這樣寫代碼，但如果你真想使用實現(xiàn)繼承，那么這才是正確的寫法！

總之一句話，OOP課程教給你什么是繼承，而你沒有學(xué)習(xí)的OOD課程本應(yīng)教給你在99%的情況下不要使用繼承！

實體 / 組件框架

有了這些背景之后，我們來看看Aras開頭提出的那些所謂的“常見的OOP”。

實際上我還要說一句，Aras稱這些代碼為“傳統(tǒng)的OOP”，而我并不這樣認為。這些代碼也許是人們常用的OOP，但如上所述，這些代碼破壞了所有核心的OO規(guī)則，所以它們完全不是傳統(tǒng)的OOP。

我們從最早的提交開始——當時他還沒有把設(shè)計修改成ECS："Make it work on Windows again"（https://github

• GameObject實現(xiàn)了服務(wù)定位器模式（Service Locator Pattern，https://en.wikipedia.org/wiki/Service_locator_pattern），這種模式可以通過類型查詢子組件。

• Component知道自己屬于哪個GameObject，它們可以通過查詢父GameObject來定位兄弟組件。

• 組合僅限于單層（Component不能擁有子組件，GameObject也不能擁有子GameObject）。

• GameObject只能有各種類型的組件各一個（有些框架要求這一點，有些不要求）。

• 所有組件（可能）都會以未知的方式改變，因此接口定義為“virtual void Update”。

• GameObject屬于場景，場景可以查詢所有GameObject（因此可以繼續(xù)查詢所有Component）。

這種框架在本世紀初非常流行，盡管它很嚴格，但提供了足夠的靈活性來支持無數(shù)的游戲，直到今天依然如此。

但是，這種框架并不是必須的。編程語言的特性中已經(jīng)提供了組合，不需要再用框架實現(xiàn)一遍……那為什么還需要這些框架？那是因為框架可以實現(xiàn)動態(tài)的、運行時的組合。

GameObject無須硬編碼，可以從數(shù)據(jù)文件中加載。這樣游戲設(shè)計師和關(guān)卡設(shè)計師就可以創(chuàng)建自己的對象……但是，在大多數(shù)游戲項目中，項目的設(shè)計師都很少，而程序員很多，所以我認為這并不是關(guān)鍵的功能。何況，還有許多其他方式來實現(xiàn)運行時組合！

例如，Unity使用C#作為其“腳本語言”，許多其他游戲使用Lua等替代品，所以面向設(shè)計師的工具可以生成C#/Lua代碼來定義新的游戲?qū)ο?，而不需要這些框架！

我們會在以后的文章里重新加入運行時組合的“功能”，但要同時避免10倍的性能開銷……

如果我們用OOD的觀點評價這段代碼：

• GameObject：GetComponent使用了dynamic_cast。大多數(shù)人都會告訴你，dynamic_cast是一種代碼異味——它強烈地暗示著代碼什么地方有問題。我認為，它預(yù)示著你的代碼違反了LSP——某個算法在操作基類的解耦，但它要求了解不同實現(xiàn)的細節(jié)。這正是代碼異味的原因。

• GameObject還算可以，如果認為它實現(xiàn)了服務(wù)定位器模式的話……但是從OOD的觀點來看，這種模式在項目的不同部分之間建立了隱含的聯(lián)系，而且我認為（我找不到能用計算機科學(xué)的知識支持我的維基鏈接）這種隱含的通信通道是一種反面模式（https://en.wikipedia.org/wiki/Anti-pattern），應(yīng)當使用明示的通信通道。這種觀點同樣適用于一些游戲中使用的“事件框架”……

• 我認為，Component違反了SRP（單一責(zé)任原則），因為它的接口（ virtual void Update(time)）太寬泛了?！皏irtual void Update”在游戲開發(fā)中非常普遍，但我還是要說這是個反面模式。好的軟件應(yīng)該可以很容易地論證其控制流和數(shù)據(jù)流。將一切游戲代碼放在“virtual void Update”調(diào)用后面完全混淆了控制流和數(shù)據(jù)流。在我看來，不可見的副作用（https://en.wikipedia.org/wiki/Side_effect_(computer_science)）——也稱為“遠隔作用”（https://en.wikipedia.org/wiki/Action_at_a_distance_(computer_programming）——是最常見的Bug來源，而“virtual void Update”使得一切都擁有不可見的副作用。

• 盡管Component類的目的是實現(xiàn)組合，但它是通過繼承實現(xiàn)的，這違反了CRP（組合重用原則）。

這段代碼好的一方面在于，它滿足了SRP和ISP（接口隔離原則），分割出了大量的簡單組件，每個組件的責(zé)任非常小，這一點非常適合代碼重用。

但是，它在DIP（依賴反轉(zhuǎn)原則）方面做得不好，許多組件都互相了解對方。

所以，我上面貼出的所有代碼實際上都可以刪掉了。整個框架都可以刪掉。刪掉GameObject（即其他框架中的Entity），刪掉Component，刪掉Find Of Type。這些都是無用的VM中的一部分，破壞了OOD的規(guī)則，使得游戲變得非常慢。

無框架組合（即使用編程語言的功能實現(xiàn)組合）

如果刪掉整個組合框架，并且沒有Component基類，我們怎樣才能使用組合來管理GameObject呢？

我們不需要寫VM再在我們自己的奇怪的語言之上實現(xiàn)GameObject，我們可以使用C++自身的功能來實現(xiàn)，因為這就是我們游戲程序員的工作。

下面的提交中刪除了整個實體/組件框架：

https://github

https://github

https://github

• 從每個組件類型中刪掉了“: public Component”。

• 給每個組件類型添加了構(gòu)造函數(shù)。

• OOD的主旨是封裝類的狀態(tài)，但這些類非常小、非常簡單，所以沒有太多東西需要隱藏，它的接口只是數(shù)據(jù)描述而已。但是，封裝成為面向?qū)ο笾е闹饕蛑皇?，它可以讓類不變量（class invariant，https://en.wikipedia.org/wiki/Class_invariant）永遠為真……或者說，在違反某個不變量時，你只需要檢查封裝的實現(xiàn)代碼就能找到Bug。在這段示例代碼中，我們值得添加一個構(gòu)造函數(shù)來確保一個簡單的不變量，即所有值必須被初始化。

• 我將過于通用的“Update”方法改名，使之能夠反映出實際功能，比如MoveComponent的叫做Update Position，Avoid Component的叫做Resolve Collisions。

• 我刪掉了三段有關(guān)模板和預(yù)制組件（Prefab）硬編碼的代碼，即創(chuàng)建包含特定Component類型的GameObject代碼，并用三個C++類來代替。

• 修正了“virtual void Update”反面模式。

• 不再讓組件通過服務(wù)定位器模式互相查找，而是讓GameObject在構(gòu)造過程中直接鏈接組件。

對象

這樣，我們不再使用下面的“VM”代碼：

for (auto i = 0; i < kObjectCount; ++i)
{
GameObject* go = new GameObject("object");
PositionComponent* pos = new PositionComponent;
pos->x = RandomFloat(bounds->xMin, bounds->xMax);
pos->y = RandomFloat(bounds->yMin, bounds->yMax);
go->AIDComponent* avoid = new AvoIDComponent;
go->AIDComponent avoid;
RegularObject(const WorldBoundsComponent& bounds)
: move(0.5f, 0.7f)
, pos(RandomFloat(bounds.xMin, bounds.xMax),
RandomFloat(bounds.yMin, bounds.yMax))
, sprite(1.0f,
1.0f,
1.0f,
rand % 5,
1.0f)
{
}};...
regularObject.reserve(kObjectCount);for (auto i = 0; i < kObjectCount; ++i)
regularObject.emplace_back(bounds);

算法


現(xiàn)在另一個難題是算法。還記得開始時我說過，接口和算法是共生（Symbotic）的，兩者應(yīng)該互相影響對方的設(shè)計嗎？“virtual void Update”反面模式也不適合這種情況。原始的代碼有個主循環(huán)算法，它的結(jié)構(gòu)如下：

for (auto go : s_Objects)
{
go->Update(time, deltaTime);

你可能會認為這段代碼很簡潔，但我認為這段代碼很糟糕。它完全混淆了游戲中的控制流和數(shù)據(jù)流。

如果我們想理解軟件，維護軟件，給軟件添加新功能，優(yōu)化軟件，甚至想讓它能在多個CPU核心上運行得更快，那么我們必須理解控制流和數(shù)據(jù)流。所以，“virtual void Update”不應(yīng)該出現(xiàn)。

相反，我們應(yīng)該使用更明確的主循環(huán)，才能讓論證控制流更容易（這里數(shù)據(jù)流依然被混淆了，我們會在稍后的提交中解決）。

for (auto& go : s_game->regularObject)
{ UpdatePosition(deltaTime, go, s_game->bounds.wb);
} for (auto& go : s_game->avoidThis)
{ UpdatePosition(deltaTime, go, s_game->bounds.wb);
}
for (auto& go : s_game->regularObject)
{ ResolveCollisions(deltaTime, go, s_game->avoidThis);
}

這種風(fēng)格的缺點是，每加入一個新類型的對象，就要在主循環(huán)中添加幾行。我會在以后的文章中解決這個問題。

性能

現(xiàn)在代碼中仍然有違反OOD的地方，有一些不好的設(shè)計抉擇，還有許多可以優(yōu)化的地方，但這些問題我會在以后的文章中解決。

至少在目前來看，這個“改正后的OOD”版本的性能不弱于Aras演講中最后的ECS版本，甚至可能超過它……

而我們所做的只是將偽OOP代碼刪除，并使用真正遵守OOP規(guī)則的代碼而已（并且刪除了100多行代碼！）。

下一步

我還想談更多的問題，包括解決殘余的OOD問題、不可更改的對象（函數(shù)式風(fēng)格編程，https://en.wikipedia.org/wiki/Functional_programming），以及對數(shù)據(jù)流、消息傳遞的論證能帶來的好處。

并給我們的OOD代碼添加一些DOD論證，給OOD代碼添加一些關(guān)系型技巧，刪掉那些“實體”類并得到純粹由組件組成的、以不同風(fēng)格互相鏈接的組件（指針 VS 事件處理），真實世界的組件容器，加入更多優(yōu)化以跟上ECS版本，以及更多Aras的演講中都沒有提到的優(yōu)化（如線程和SIMD）

當前標題：面向?qū)ο缶幊桃阉?，OOP 永存
當前鏈接：http://www.rwnh.cn/news31/102431.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供服務(wù)器托管、網(wǎng)站維護、做網(wǎng)站、微信公眾號、外貿(mào)網(wǎng)站建設(shè)、網(wǎng)站制作

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)