【專案日誌】山鴉行動 泛型、繼承、物件池和音效 10/22

標題越來越長 :P

這周
繼續趕工，這次搞出了一個物件池模板，和音效物件池

現在我做自己的通用函式庫都盡量維持一些原則，不要實作任何「可能」會用到的功能，只寫「一定」會用到的部份。之前嘗試搞過幾種自製系統了，道具庫存什麼的，然後每次我想到什麼可能會用到的功能就先加上去，但需求是無限的，亂亂加最後都會被改到四不像，結果做出來也沒用幾次就扔ㄌ

就算用繼承、多型也是一樣，物件導向裡繼承比較為人詬病的點就是基底類別容易膨脹。有時為了降低所謂的「程式碼重複」就把子類的函式移到父層，讓子類能調用，但真的需要這項函式的也就一兩個類別而已。再加上以前我也還不熟泛型 Generic<T>，結果最後就把整個函式庫搞的亂七八糟，留下一堆超級肥的基底類別

順帶一提，繼承的應用可以參考設計模式「子類別沙盒」(Subclass Sandbox)，有興趣的可以自己查，物件導向基礎。

總之，前天我就根據這項原則我就把自己寫的物件池模板化了，一樣是用 ScriptableObject 令牌的作法。可能需要的需求就用抽象、虛擬和泛型預留空間給使用者實做，模板只完成物件池裡的必要功能而已，沒有一行多餘的程式。


然後再擴展出音效池的功能。


度的，我查資料才發現 Monobehaviour 是允許泛型的，只不過要先繼承過，不然 Interface 沒辦法預先實作函式是一大硬傷。

Type 指的是 Unity 的物件型別，物件池中儲存的原始物件或參考，上面的例子裡就是音效池的原始音檔 AudioClip。

Token 是令牌模板，運作原理就和前幾篇日誌的令牌一樣。

Container 是物件容器，例子裡就是一個具有 AudioSource 的 Gameobject。

同樣，這種作法也不需要讓音效使用者接觸到音效池本身，完美封裝，沒有任何靜態和單例。
到是有些執行順序上的設計要在考量，還要不斷修正才能抓到感覺就是了。

把音效套上 UI

因為模板預留了彈性，沒有把儲存參考物件的方式寫死（就是上面說的 Type），所以我令牌可以實做其他種 PropertyField。剛好音效有隨機的要求，現在可以直接把要隨機的音效包進令牌裡，直接抽，不用在 Monobehaviour 的組件上弄一堆陣列，方便多了。

我還在思考那個 lifeTime 是不是該換種方法做，原本只有一個參考沒問題，但現在變成隨機的了，用 struct 或 tuple 把兩個資料包在一起傳可能會好點。

唯一的缺點應該就是不能隨裝即用吧，因為只是單純的模板，所以用之前還要自己建立三個類別繼承。以前可能有 ABC 三種需求的話，我就會全部都做進去，出現 DE 的需求就再加，這樣才能作到隨裝即用，把所有可能的需求都完成好。

但就取捨吧，已經拋棄原本的觀念了，變成只做出 ABCDE 所有各種需求一定會重疊的部份，畢竟我現在想要的是避免內容膨脹到難以維護

ㄎㄅ剛 Build 好就有問題，文本沒初始化到把整個 UI 癱瘓，執行順序真的有夠頭痛的，每次那些 Build 才出現的 BUG 都馬執行順序搞的