靈感

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

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

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

Aras幻燈片的鏈接：

• https://github

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

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

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

這種結構的文章很讓我惱火，因為：

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

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

面向對象編程的歷史也同樣悠久（實際上比關系模型還要久，它的概念從上世紀五十年代就出現了）！但是，直到九十年代，OO才得到人們的背景

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

• 抽象

• 封裝

• 多態

• 繼承

我更傾向于稱他們為“OOP的四大工具”而不是四大支柱。這些工具可以用來解決問題。但是，只學習工具的用法是不夠的，你必須知道什么時候應該使用它們。

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

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

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

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

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

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

這才是我們的SOLID C++。

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

一點其他看法：

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

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

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

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

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

• 在C++中，實現繼承發生在一切基類包含純虛函數以外的內容的情況。在Java中，實現繼承用Extends關鍵字表示。

• OOD定義了許多關于接口繼承的規則，但實現繼承通常是不祥的預兆（https://en.wikipedia.org/wiki/Code_smell）。

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

在學習層次結構和繼承時，你很可能學習過以下類似的例子：

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

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

在學習層次結構和繼承時，你很可能學習過以下類似的例子：

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

這個例子其實很好地演示了實現繼承和接口繼承之間的區別。

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

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

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

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

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

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

• 所以，OOD實際上并不鼓勵實現繼承。前面說過，如果你要復用代碼，OOD認為應該使用組合！

• 所以，上面實現繼承的層次結構代碼的正確版本，用C++來寫應該是這樣：

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，在實現一個接口時使用。

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

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

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

實體 / 組件框架

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 我認為，Component違反了SRP（單一責任原則），因為它的接口（ virtual void Update(time)）太寬泛了。“virtual void Update”在游戲開發中非常普遍，但我還是要說這是個反面模式。好的軟件應該可以很容易地論證其控制流和數據流。將一切游戲代碼放在“virtual void Update”調用后面完全混淆了控制流和數據流。在我看來，不可見的副作用（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類的目的是實現組合，但它是通過繼承實現的，這違反了CRP（組合重用原則）。

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

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

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

無框架組合（即使用編程語言的功能實現組合）

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

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

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

https://github

https://github

https://github

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

• 給每個組件類型添加了構造函數。

• OOD的主旨是封裝類的狀態，但這些類非常小、非常簡單，所以沒有太多東西需要隱藏，它的接口只是數據描述而已。但是，封裝成為面向對象支柱的主要原因之一是，它可以讓類不變量（class invariant，https://en.wikipedia.org/wiki/Class_invariant）永遠為真……或者說，在違反某個不變量時，你只需要檢查封裝的實現代碼就能找到Bug。在這段示例代碼中，我們值得添加一個構造函數來確保一個簡單的不變量，即所有值必須被初始化。

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

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

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

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

對象

這樣，我們不再使用下面的“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);

算法


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

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

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

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

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

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);
}

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

性能

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

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

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

下一步

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

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

當前標題：面向對象編程已死，OOP 永存
當前鏈接：http://m.newbst.com/news31/102431.html

成都網站建設公司_創新互聯，為您提供服務器托管、網站維護、做網站、微信公眾號、外貿網站建設、網站制作

廣告

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