物件導向的程式設計在遊戲開發中使用（三）：三大特性

對於類和方法，我們已經有了一個初步的認識。而假如你聽說過物件導向，很大可能會聽說過物件導向的三大特性。如果你沒聽說過，那麼你現在聽說了。

1繼承

我們再類的裡面已經提到過繼承，但是重點是什麼是繼承。而在三大特性角度來看，我們更要討論如何繼承。

出於這個目的，一方面我們應該把更多通用的內容交給父類，並且讓父類儘可能多的適應大部分狀況，另外一方面我們不應該讓一個基本的類失去他的公正性，我們可以讓程式碼向更常用的方向傾斜，但是應該對少數但是必要的子類給以足夠的支援。

繼承另外的一個很重要問題，子類之間應該在互動上有一定的相似性，用我們一直在舉的例子，筆。隨著科技的發展，最早從鉛筆，到現在的中性筆、太空筆，雖然外觀和技術有顯著的更新，但是作為互動的方式，大體上都沒有變。

也因此，我們在設計類和子類的同時，應該考慮到實際使用時，對於筆、上墨器、人手等等與筆的互動，是否相似。對於我個人的意見，這種通用性的經驗，應該交給父類來進行，並把其中更加自由的部分作為額外的函式交給子類來獨特的定義，最大的保證使用時不會給其他物體帶來不便。

2封裝

我們知道，任何一個類裡面有種種屬性，玩家有血量，筆有墨量。

在物件導向的程式設計裡面，我們更希望讓自己的屬性受到自己的控制。就像你的錢，你更希望自己親手交給別人，而不是放在桌子上讓別人自由的拿對吧？

封裝這一特性就在於，讓類自己的屬性，更多的由自己來控制。基本的表現就是大量的setter和getter，我不是很清楚這兩個詞要怎麼準確的翻譯。對於外部所需要的改變，玩家損失了血量，在這種思想下，這個血量不應該由世界或者其他的什麼大的方面改變，而是要在玩家類內設定修改自己血量的方法。

那麼好處呢？很簡單的一點，假如我們在遊戲中加入損失血量觸發的特效或者物品，我們就不需要遊離於各種各樣的程式碼之間尋找當初損失血量時的種種操作，而對於更多的問題，這種修改可能遍佈整個程式碼當中。這很恐怖對吧？而當我們完成了封裝，我們只需要加入玩家或者他們的父類裡，血量的setter進行相應的修改就可以了。這對一個簡單的遊戲沒什麼，但是對於複雜或者開發週期很長的遊戲，封裝是一種很重要的思想。

3多型

說到多型，就是耦合性，但是這兩個詞沒有之前的內容顯而易見。

但是多型的概念本身已經在前文略加描述過，而這段，會在之前的基礎上進一步用使用的角度來展示。

在以前，計算機使用各種各樣的介面，印表機、串列埠、PS2，但是現在呢？我們看到他們大部分被USB取代了，這基本上就是耦合性的概念。

耦合性意味著對於現有的程式碼，我們在開發新功能，加入新模組的同時，對於原有程式碼的改動有多大。而耦合性高的程式碼，就像一件定製的西裝一樣的昂貴，對其進行改變就會付更多的代價。

於是就有了多型，與現實相似在程式設計的時候我們也希望有類似USB這種通用性很高的介面，而介面本身也是一種程式設計概念，但這個概念我們現在不討論。

我們希望有這樣一種讓我們面對大部分，理想上是所有的情況，都能使用更通用的方法。比如筆可以在紙上寫字，那對於寫字的人來說，更多的希望對所有筆都有相似的互動方式，這在實際程式設計時就變成了，對於一些子類，我們希望他們的父類提供一個更統一的方法來讓我們使用，而需要父類可以掌握並找到子類的函式。同時希望我們為父類編寫的程式碼同樣適用於他的子類。

如之前所講，這個概念在前面已經提過，在遊戲中程式設計，我們會看到許多初始化完成，或是邏輯幀處理，或是繪圖幀處理。當遊戲程式中，會自發的呼叫這些邏輯或者繪圖幀，而我們要做的和這些類似，讓我們更大一層次的程式碼，使用更通用的方法呼叫，並把決定細節交給內部。C++為我們提供了虛擬函式，C我們可以直接使用函式指標，而更新興的語言會更直接的提供這種方法。

系列文章
物件導向的程式設計在遊戲開發中使用（一）：類
物件導向的程式設計在遊戲開發中使用（二）：方法
物件導向的程式設計在遊戲開發中使用（三）：三大特性

作者：Kingfeng
來源：奶牛關
原地址：https://cowlevel.net/article/2051328