在我們的開發項目中使用MVC（Model-View-Control）模式的益處是，可以完全降低業務層和應用表示層的相互影響。此外，
我們會有完全獨立的對象來操作表示層。MVC在我們項目中提供的這種對象和層之間的獨立，將使我們的維護變得更簡單使
我們的代碼重用變得很容易（下面你將看到）。
作為一般的習慣，我們知道我們希望保持最低的對象間的依賴，這樣變化能夠很容易的得到滿足，而且我們可以重復
使用我們辛辛苦苦寫的代碼。為了達到這個目的我們將遵循一般的原則“對接口編成，而不是對類”來使用MVC模式。
我們的使命，如果我們選擇接受它．．．
我們被委任構建一個ACME 2000 Sports Car項目，我們的任務是做一個簡單的Windows畫面來顯示汽車的方向和速度，
使終端用戶能夠改變方向，加速或是減速。當然將會有范圍的擴展。
在ACME已經有了傳言，如果我們的項目成功，我們最終還要為ACME 2 Pickup Truck 和ACME 1 Tricycle開發一個相
似的接口。作為開發人員，我們也知道ACME管理團隊最終將問“這樣是很棒的，我們能夠在我們的intranet上看到它？”
所有的這些浮現在腦海中，我們想交付一個產品，使它能夠容易的升級以便能夠保證將來我們能夠有飯吃。
所以，同時我們決定“這是使用MVC的一個絕好情形”
我們的構架概要
現在我們知道我們要使用MVC，我們需要指出它的本質。通過我們的試驗得出MVC的三個部分：Model，Control和View。
在我們的系統中，Model就是我們的汽車，View就是我們的畫面，Control將這兩個部分聯系起來。
為了改變Model（我們的ACME 2000 sports car），我們需要使用Control。我們的Control將會產生給Model
（我們的ACME 2000 sports car）的請求，和更新View，View就是我們的畫面（UI）。
這看起來很簡單，但是這裡產生了第一個要解決的問題：當終端用戶想做一個對ACME 2000 sports car一個改變將
會發生什麼，比如說加速或是轉向？他們將通過View（our windows form）用Control來提出一個變化的申請。
現在我們就剩下一個未解決問題了。如果View沒有必要的信息來顯示Model的狀態怎麼辦？我們需要再在我們的圖中
加入一個箭頭：View將能申請Model的狀態以便得到它要顯示的相關狀態信息。
最後，我們的最終用戶（司機）將會和我們的ACME Vehicle Control系統通過View來交互。如果他們想發出一個改
變系統的申請，比如提高一點加速度，申請將會從View開始發出由Control處理。
Control將會向Model申請改變並將必要的變化反映在View上。比如，如果一個蠻橫的司機對ACME 2000 Sports Car
做了一個"floor it"申請，而現在行駛的太快不能轉向，那麼Control將會拒絕這個申請並在View中通知，這樣就防止了
在交通擁擠是發生悲慘的連環相撞。
Model (the ACME 2000 Sports Car) 將通知View 它的速度已經提高，而View也將做適當的更新。
綜上，這就是我們將構建的概要：
開始
作為總是想的遠一點的開發人員，我們想讓我們的系統有一個長久並且良好的生命周期。這就是說能夠進可能的
准備好滿足ACME的很多變化。為了做到這一點，我們知道要遵循兩條原則．．．“保證你的類低耦合”，要達到這個
目標，還要“對接口編程”。
所以我們要做三個接口（正如你所猜測，一個Model接口，一個View接口，一個Control接口）。
經過很多調查研究，和與ACME人的費力咨詢，我們得到了很多有關詳細設計的信息。我們想確定我們可以設置的最
大速度在前進，後退和轉彎中。我們也需要能夠加速，減速，左轉和右轉。我們的儀表盤必須顯示當前的速度和方向。
實現所有這些需求是非常苛刻的，但是我們確信我們能夠做到．．．
首先，我們考慮一下基本的項目。我們需要一些東西來表示方向和轉動請求。我們做了兩個枚舉類型：
1 2 3 4 5 6 7 8 9
AbsoluteDirection 和 RelativeDirection。
public enum AbsoluteDirection
{
North=0, East, South, West
}
public enum RelativeDirection
{
Right, Left, Back
}
下面來解決Control接口。我們知道Control需要將請求傳遞給Model，這些請求包括：Accelerate, Decelerate,
