結對編程---附加題做業(做業請參考相應博客)

結對編程 附加做業 

毛宇 11061171

程志 10061188

 

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

 

其實在學習這個框架的過程當中，咱們有不少不少的感覺。

整體評價這個框架，感受寫得很是的規範，特別是接口的設計讓人以爲耳目一新，可是仍是存在着一些小問題，好比：

 

1. 我很是不能理解的一點就是關於層高10，爲何不能用_FLOOR_HEIGHT_這樣的宏定義，這樣的接口設計讓人以爲很是無力，並且若是修改起來，也很是麻煩。

 

1. 其實我沒有懂的一點就是，我看見說明裏面有人數限制，可是具體API中沒有，敢問實際電梯中還有人數的限制嗎？電梯如何檢測上來了多少人，這一點以爲很荒唐，也不少餘，若是想讓學生更好的練習算法，儘可能吧這些細節設計得日常一點，不要這麼奇葩。

 

3．接口中有些常量名字取得讓人覺的很難理解，好比」 DirectionReqSource」，爲何不能用start_floor來替代Source呢，在這樣一個沒有文檔的框架中，變量起名絕對是很是重要，由於它直接決定了學生理解其的難度。好比Tick,爲何不能用Second來代替，等等等等。總之，我但願這些名字最好直觀口語化。

 

 

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

 

實現一個UI界面的方法其實很簡單，咱們的做業中在solution下新建了一個WinForm工程，而後設置main函數開始運行的時候，winform工程也開始啓動。這裏其實藉助了遊戲開發的思想（相似的遊戲開發思想在Cocos2d-x引擎以及微軟XNA框架下比比皆是），也就是「輪詢機制」，在每一幀的時候刷新當前電梯的位置的狀況，從而達到動畫的效果。

 

 

具體的代碼已經遷入到TFS上面。（由於設計到部分框架下代碼的改動（主要是幾處成員變量改成了public形））

 

此外，爲了達到更好的用戶體驗，咱們還加入了測試文件的選擇對話框：

 

 

 

在實現的過程當中遇到了一些問題，好比C#不接受跨線程訪問UI，這個問題開始困擾了咱們好久，後面在百度知道求助專家，終於恍然大悟，經過改變安全等級來消除了這個問題，這裏感謝百度網友 「矮矮的小孩」和」黑人_九天」的相助。

 

#3 [附加題]  閱讀有關 MVC 和  MVVM 設計模式的文章。

 

首先貼出來一個MVC的定義

「MVC，是模型(model)－視圖(view)－控制器(controller)的縮寫，一種軟件設計典範，用於組織代碼用一種業務邏輯和數據顯示分離的方法，這個方法的假設前提是若是業務邏輯被彙集到一個部件裏面，並且界面和用戶圍繞數據的交互能被改進和個性化定製而不須要從新編寫業務邏輯。MVC被獨特的發展起來用於映射傳統的輸入、處理和輸出功能在一個邏輯的圖形化用戶界面的結構中。」

 

其實我我的的理解是，咱們MVC是一種設計的結構，使得構成軟件中三個比較重要的要素可以相互獨立。舉個例子，Android中的Activity（能夠理解爲界面）的開發使用了Xml，將控件（模型）添加到界面中 ，而且調整大小布局（視圖）。而控制器，也就是邏輯代碼的則採用了java，這樣有一個好處，就是使之相互獨立了起來。相比之下，這樣的開發結構使得耦合性，重用性，可維護性都大大提升。

 

在這個項目中，基於WinForm工程的UI設計就是一個很好的例子，控件（好比Label等）就是模型，佈局就是視圖，而後邏輯代碼就是控制器。

 

可是我我的以爲像電梯調度框架這樣的比較小的項目，沒有必要去採用MVC模式，由於過於在中小型的應用中強調這種模式確定會浪費大量的時間。

 

 

#4 [附加題] 咱們如今的題目是假設全部電梯到達全部的樓層。  在現實生活中,  多部電梯到達的樓層都不同。若是是這樣 (例如3號電梯能到達10 – 20 層,    4 號電梯能到達5-15 層)，整個程序框架和你的電梯調度模塊要作什麼改變? 

 

若是對於電梯的樓層作出了限定，那麼改變的方法其實也很是簡單。

主要的改變我我的認爲應該是在電梯模塊中，就是電梯對請求的處理中要增長出一個斷定，好比某乘客要去4層，電梯不能去4層，就忽略這個乘客。

應該其餘地方是不須要改變的（這個問題是想側面證明框架中給出的設計優越性嗎？）