物件導向的程式設計在遊戲開發中使用（二）：方法

我並不是遊戲開發的從業人員，甚至連軟體開發都不是，但至少我是程式設計師。


我認為，一個【物件導向】的理念在學習過程中的重要性遠大於對於程式碼本身含義的認識。


這一點可以在諸多書籍中得到論證，但很奇怪的一件事是，絕大部分的視訊入門教程和並沒有過多的強調這一點。


系列收藏夾：https://cowlevel.net/collection/3476202

我們在類的部分已經簡單的介紹了什麼是類

在這裡，我用一張簡潔的圖來回顧上一篇文章的內容


程式裡的一支筆，對於我們顯然不是為了把他作為一個觀賞品

我們要利用筆的概念製造出筆，在程式碼中與其他的類進行互動

當然，製造的部分不是我們這次的內容，我們要做的是為我們的類加入互動的方法

0虛擬碼

在之後的內容，為求簡介（和類不同，方法和其他一些東西並沒有日常中的例子可以方便的舉出

在文章中會出現”虛擬碼“形式的內容

但請放心，這些虛擬碼並不是任何程式設計的一部分，只是作為高度的概括來節省篇幅

並使用諸如箭頭或是其他更加形象的內容，來代替隱晦的語法和符號

1函式

在真正認識到方法之前

大部分人先聽過的概念更多的是函式

在大部分的情況下，如果你去搜尋函式與方法的區別，更有可能搜尋到的是某一門語言（比如python）對於這二者之間稱呼上進行區分的，這些區別並非是錯的，只是出發點不同。

函式和方法之間最大的區別，是物件導向和不物件導向。

如果你在設計層面，面向的是一個物件，那麼你寫出來的就是方法。

這還不夠現實，對嗎?

那我們舉個例子，暫時忘掉之前的物件導向。

我們拿筆在寫字或者亂塗亂畫之類的，實質上是一個吧筆裡的墨水沾到紙上的過程。那我們就來寫寫看


看起來還可以對吧？

但是這裡面的每一行在實際的專案中可能都是數十甚至數百行程式碼，而且這些步驟可能是互相穿插的，不論編寫時會造成邏輯上的混亂，就是在糾錯時也會很容易的吧自己轉的暈頭轉向。

更可怕的是接下來更大的麻煩，我如果新加入了鉛筆，甚至羽毛筆怎麼辦，對這些程式碼的修改會不會影響到其他筆的使用，要怎麼做區分？？

2方法

於是我們就有了方法。

對於上面的問題，當然很簡單，我們只需要把這些步驟獨立出來就好了嘛。

首先我們編寫一個從筆尖獲取形狀的函式，然後寫一個筆消耗墨水的函式，最後再寫一個吧墨水蓋在紙上的函式，很簡單對嘛？幾乎沒有什麼變動，但是這種思想已經向著物件導向前進很多了。

我們撿起上篇文章的內容，從功能的角度來思考。

對於一支筆，他的形狀是根據筆尖決定的，受到桌面或者紙的影響，但是我們姑且不考慮這些，更復雜的東西我們以後再說。

那麼決定形狀就是筆尖的功能了，當然還有出墨量。那麼我們為筆尖創造一個方法，讓筆尖生成一個形狀。

看不出來有什麼區別嘛?這個同樣等下再說。

同樣的，我們給我們的墨囊或是其他的什麼東西創造一個方法讓他擠一些墨水出來。

再給紙張加個方法讓他可以吧墨跡放在自己身上。

3方法（續）


我們現在吧生成墨跡交給了筆，吧沾上墨跡交給了一個函式，這雖然還是函式，但是已經距離方法很近了。

就像我們從藥店買的藥都會有說明書，電器也會有，其他都會有。

我們想想說明書告訴了我們的事，那是現實意義上的方法。當我們拿到了一件東西，去看他的說明書，而這時我們需要掌握的並非對物品的使用經驗或是之類的，而變成需要語言的閱讀能力來閱讀說明書。

當我們把這個“說明書”寫進程式碼之中


當我們有多個筆，多種紙，我們就不用改動【生成墨跡】的程式碼，而只需要重新編寫筆相應的生成墨跡的方法。。

就像例子裡所說的，我們編寫一個會閱讀筆尖說明書的函式，再給每個筆尖放上一個說明書，就踏出了從函式走向方法的最後一步。

在C語言或者一些更古老的語言中，我們需要一些技巧來完成說明書，但是更先進的語言裡，我們已經可以直接吧說明書以函式的形式寫在類裡面了，當然如何寫並不在我們文章的範圍裡。

4方法帶來的便利

那麼方法到底帶給了我們什麼樣的好處。

首先一點，最直觀的，當我們用其他筆的時候，可以重寫這個說明書，使用同樣的格式重寫，函式會讀到新的說明書，直觀的造成改變。

同樣，如果對原有的說明書不滿意，可以更方便的改寫他，然後就可以影響使用這個說明書的所有個體。

而深入一些，你在功能還為編寫時你甚至可以用簡單的一個固定形狀來代替你筆尖的形狀變化，等到其他部分完成再回過頭來讓你的筆尖可大可小。

也可以在你製作筆尖的時候讓你使用一個更簡單的紙張，而不用考慮因為複雜紙張的程式碼引發的筆尖BUG

這只是表面上的便利性，更多的內容我們會在下篇文章繼續！

系列文章：
物件導向的程式設計在遊戲開發中使用（一）：類

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