MVC

gof設計模式—smalltalk mvc筆記

mvc通過建立一個“訂購 /通知”協定來分離視圖和模型。視圖必須保證它的顯示正确地反映了模型的狀态。一旦模型的資料發生變化，模型将通知有關的視圖，每個視圖相應地得到重新整理自己的機會。這種方法可以讓你為一個模型提供不同的多個視圖表現形式，也能夠為一個模型建立新的視圖而無須重寫模型。

這樣當然能為一個模型提供多個視圖啦，因為模型不屬于某一個具體的視圖，這樣誰都可以去使用它了。個人覺得mvc隻适合用在一對多的情況下，一個模型對多個視圖。不然這種分離沒有啥意義，反而使模型和視圖太松散了。

将對象分離，使得一個對象的改變能夠影響另一些對象，而這個對象并不需要知道那些被影響的對象的細節。這個更一般的設計被描述成 observer模式。

将對象分離就是将視圖、模型、控制器分離，使模型不依賴于視圖和控制器，但這樣的話就會出現一個問題，當模型狀态更新時，如何通知視圖觸發更新？如果直接通過模型通知視圖，那麼又會導緻依賴性，為了解決這個問題，引入了observer模式，當模型狀态更新時，由觀察器通知其他對象更新狀态。各個視圖實作observer接口，并向模型注冊。模型将跟蹤由訂閱更改的所有觀察器組成的清單，當模型發生改變時，模型将會周遊所有已注冊的觀察器，并将更改通知它們，此方法通常稱為"釋出-訂閱"。

代碼1：

模型不直接通知視圖，而是通知觀察器，由觀察器來通知。

之前的做法可能會是下面這樣：

由于模型和視圖直接接觸，導緻一旦再添加視圖或删除，都需要去操作模型内部代碼，如果代碼是自己寫還好，如果交由同僚，這種寫法就不是很好了。以上代碼還算好的了，如果将模型和資料混在一起，當新增一個模型時又得重新寫一份模型了。

在這幾段代碼中，我發現控制器的概念就不是那麼強烈了，可有可無，因為控制器的作用就是解釋使用者的滑鼠和鍵盤輸入，以通知模型或視圖進行相應的更改，而在web浏覽器中，我們隻需要通知模型，而通知模型web浏覽器提供了事件機制。

在代碼1中，由于模型繼承至觀察器，而某些語言如javascript，它就隻支援單繼承，是以這種做法會導緻它無法繼承至其他對象，一個可行的解決方案是将觀察器寫在模型中。

将一些對象劃為一組，并将該組對象當作一個對象來使用。這個設計被描述為c o m p o s i t e 模式，該模式允許你建立一個類層次結構，一些子類定義了原子對象（如b u t t o n）而其他類定義了組合對象（ c o m p o s i t e vi e w ），這些組合對象是由原子對象組合而成的更複雜的對象

從細顆粒到一粒再由粒組合粒成為一個組，由組再組合形成一個對象，如果要使用原子對象，那麼得考慮清楚是否有必要，畢竟原子對象太過于原始，要說組合，function就是最好的例子。

一個政策是一個表述算法的對象。當你想靜态或動态地替換一個算法，或你有很多不同的算法，或算法中包含你想封裝的複雜資料結構，這時政策模式是非常有用的。

每個算法都是獨立的，使用的時候傳遞相應的算法。

m v c 的主要關系還是由 o b s e r v e r 、c o m p o s i t e 和s t r a t e g y 三個設計模式給出的。

模型-視圖-控制器

observer（觀察器）