PairWork-電梯排程程式結對程式設計【附加題】

Hello_Jane發表於2014-10-17
AI程式設計

1 介面改進

　　1) 之前判斷電梯是否閒置的函式不太好理解，重新修改了，如下所示：

        //是否停頓狀態（停止的以及開門間隔>=0）
        public bool IsIdle
        {
            get
            {
                return CurrentStatus.CurrentDirection == Direction.No
                    && CurrentStatus.DoorCloseOpenTicks < 0;
            }
        }

　　2) 原來的程式將每一個電梯的target都初始化為0，感覺並不合理。因為最開始電梯的狀態應該是沒有目標樓層的，而且在我們的演算法中target如果一開始為0，會導致重複開門的問題。所以我們把target初始化為-1，代表電梯那時候並沒有目標樓層。

　　3) IElevator介面中定義的函式public bool ReqStopAt(int targetFloor) ，先看函式名很容易讓人聯想到這個函式的作用是是排程電梯前往目標樓層，再看它的返回值是布林型別，也就自然想到返回值標誌著是否成功到達目標樓層。可是 看具體的函式時，發現這個函式其實主要作用是將targetFloor這個引數的值賦給電梯的target，修改當前方向，並未把target如何具體發 生改變的過程展現出來，而且返回值標誌的是是否接受排程請求。所以感覺這個函式的問題要麼是名字起得不好，要麼是實現過程和名稱不符。

　　其實這個函式的主要作用就是更新電梯狀態（包括當前執行方向以及當前的目標樓層），所以我們覺得這部分程式碼完全可以放到StatusUpdateForEveryTick(int ticks)這個函式裡，感覺這樣更方便使用。

2 UI設計

　　執行時的窗體用錄屏工具做成了視訊，然後轉成了gif，就是有點小（免費軟體理解一下）……

                                                  

　　主要的介面設計參照了上一級某Pair的設計，但是鑑於時間關係我們只展示了電梯的執行，沒有展示出乘客的狀態。

　　

　　不過做到這一點已經比較糾結了，因為窗體是在主執行緒建立的，而TickGoes中如果想對窗體的控制元件進行修改的話是不允許的。參考的Pair用的方法我們試著沒有成功……最後用了委託這個東西，但是比較遺憾的是不能不能直接重複開始，要關掉重來才可以。

　　限於時間關係關係暫時只能這樣了。這一版沒有上傳TFS，這個沒有關係吧？

　　需要的話可以在部落格貼出程式碼。　

3 MVC與MVVM

　　3.1 MVC(Model View Controller)

　　即模型(model)－檢視(view)－控制器(controller)。
　　MVC本來是存在於Desktop程式中的，M是指資料模型，V是指使用者介面，C則是控制器。使用MVC是將M和V的實現程式碼分離，從而使同一個程式可以使用不同的表現形式。比如一批統計資料你可以分別用柱狀圖、餅圖來表示。C存在的目的則是確保M和V的同步，一旦M改變，V應該同步更新，從例子可以看出MVC就是Observer設計模式的一個特例。

　　優點：
　　1) 低耦合性
　　2) 高重用性和可適用性
　　3) 較低的生命週期成本
　　4) 快速的部署
　　5) 可維護性
　　6) 有利於軟體工程化管理
　　缺點：
　　MVC的缺點是由於它沒有明確的定義，所以完全理解MVC並不是很容易。使用MVC需要精心的計劃，由於它的內部原理比較複雜，所以需要花費一些時間去思考。由於模型和檢視要嚴格的分離，這樣也給除錯應用程式帶來了一定的困難。每個構件在使用之前都需要經過徹底的測試。一旦構件經過了測試，就可以毫無顧忌的重用它們了。
　　根據開發者經驗，由於開發者將一個應用程式分成了三個部件，所以使用MVC同時也意味著將要管理比以前更多的檔案。
　　MVC並不適合小型甚至中等規模的應用程式，花費大量時間將MVC應用到規模並不是很大的應用程式通常會得不償失。
　　MVC設計模式是一個很好建立軟體的途徑，它所提倡的一些原則，像內容和顯示互相分離可能比較好理解。但是如果你要隔離模型、檢視和控制器的構件，你 可能需要重新思考你的應用程式，尤其是應用程式的構架方面。如果你肯接受MVC，並且有能力應付它所帶來的額外的工作和複雜性，MVC將會使你的軟體在健壯性，程式碼重用和結構方面上一個新的臺階。
 
　　3.2 MVVM
　　MVVM模式和MVC模式一樣，主要目的是分離檢視（View）和模型（Model），有幾大優點：
　　1) 低耦合：檢視（View）可以獨立於Model變化和修改，一個ViewModel可以繫結到不同的"View"上，當View變化的時候Model可以不變，當Model變化的時候View也可以不變。
　　2) 可重用性：你可以把一些檢視邏輯放在一個ViewModel裡面，讓很多view重用這段檢視邏輯。
　　3) 獨立開發：開發人員可以專注於業務邏輯和資料的開發（ViewModel），設計人員可以專注於頁面設計，使用Expression Blend可以很容易設計介面並生成xaml程式碼。
　　4) 可測試：介面素來是比較難於測試的，而現在測試可以針對ViewModel來寫。
 
　　3.3 關於這次程式
　　這次是相當於先寫好了模型（M），然後寫檢視（V）。至於控制器，也就是M、V之間的同步。這次並沒有特別好的把這幾個獨立分開，……同步機制搞得很糾結，現在這版UI只能說是差強人意啊。

相關文章