我們在Part 3已經實作了棋盤最基礎的2個功能,下子與翻子。
我們在這一篇要做的是加入黑白棋的遊戲規則。
閱讀全文〈MVP Pattern: Part 4 黑白棋範例 之二〉
分類: 設計模式
MVP Pattern: Part 3 黑白棋範例 之一
我們要實做的是黑白棋(Othello),做為一個簡單的棋盤回合制遊戲,加上使用者需要透過介面來進行操作,因此適合做為MVP的使用範例。
基於篇幅,範例分成2篇來編寫,本篇Part3與下一篇Part4。
Part3描述如何利用MVP來實現棋盤邏輯。Part4接著講解如何加入玩法邏輯,以及MVP區塊如何與其它程式邏輯來溝通。
閱讀全文〈MVP Pattern: Part 3 黑白棋範例 之一〉
MVP Pattern: Part 2 Supervising Controller
Supervising Controller與Passive View的不同點在於,它允許View直接獲取Model的資料,獲取的手段可以透過事件附帶的參數,或是透過事件通知後,再自行獲取資料。
雖然講是這樣講,但對於還不認識MVP的人來說,應該還沒理解到Supervising Controller的模糊地帶。
閱讀全文〈MVP Pattern: Part 2 Supervising Controller〉
MVP Pattern: Part 1 Passive View
MVP(Model-View-Presenter)模式,是MVC(Model-View-Controller)模式的變體,主要被使用在GUI的架構。其特徵是有個做為「中間人」的Presenter,負責協調Model和View之間的事件與資料變化。
閱讀全文〈MVP Pattern: Part 1 Passive View〉
不要依賴Singleton Pattern
注意我說的是依賴,不是說完全不該用。
你對下面的情境很熟悉嗎?
現在你有一個Enemy類別,你希望它能夠知道玩家的位置,因此他需要擁有Player物件的transform。因為Enemy實體通常都是執行期產生的,所以你不會想用GameObject.Find(如果你還不知道,你現在該知道了),也不可能使用Serialized Field。 通常下一瞬間就是,「把Player變成singleton」。嗯...好吧!的確如果你的Player實體只會有一個,那麼使用singleton好像也是可以接受的。