PairProject 電梯調度【附加題】

時間 2019-11-30

標籤 pairproject 電梯調度附加題简体版

原文原文鏈接

[附加題] 改進電梯調度的interface 設計, 讓它更好地反映現實, 更能讓學生練習算法, 更好地實現信息隱藏和信息共享。算法

目前的設計有什麼缺點, 你會如何改進它? 設計模式

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)這個函數裏，感受這樣更方便使用。spa

[附加題] 目前的這個測試程序只有命令行界面, 請給它設計UI界面, 顯示乘客/電梯的運動, 並實現之。命令行

　　運行時的窗體用錄屏工具作成了視頻，而後轉成了gif，就是有點小（免費軟件理解一下）……線程

　　主要的界面設計參照了上一級某Pair的設計，可是鑑於時間關係咱們只展現了電梯的運行，沒有展現出乘客的狀態。設計

　　不過作到這一點已經比較糾結了，由於窗體是在主線程建立的，而TickGoes中若是想對窗體的控件進行修改的話是不容許的。參考的Pair用的方法咱們試着沒有成功……最後用了委託這個東西，可是比較遺憾的是不能不能直接重複開始，要關掉重來才能夠。調試

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

　　須要的話能夠在博客貼出代碼。　

[附加題] 閱讀有關 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來寫。