我們在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好像也是可以接受的。