我的同組人是潘學
依然是之前的觀點，我認為結對編程會在項目正式開始編寫之前花費更多的時間。在開始編程之前，我們都有等着對方開始做，我再開始的想法，於是把這個 編程項目拖了很久才開始。但真正開始之后，我們由於相互過問對方的進度，反而感受到了壓力，逼着自己更快地完成自己的任務，使自己再被問到時候可以不回尷 尬，最好還能有一些超額完成來讓自己小小的自豪一下。
我覺得我的優點在於我有耐心，可以靈活運用找到的資源，學習能力強。但我的缺點在於我編程能力較弱。我的隊友潘學的優點在於他做事積極，對交給他的任務有責任心，可以細心地完成任務，缺點在於比較隨性，有時不會按照計划時間完成任務。
信息隱蔽指在設計和確定模塊時，使得一個模塊內包含信息(過程或數據)，對於不 需要這些信息的其他模塊來說，是不能訪問的。在面向對象方法中，信息隱蔽是通過對象的封 裝性來實現的。信息隱蔽的概念與模塊的獨立性直接相關。
信息隱藏，接口定義，松耦合，使程序具有良好的封裝性，便於擴展功能而不影響原有的類
封裝的一個主要的好處，就是增加軟件代碼的內聚性。通過增加內聚性，進而提高可復用性和可維護性。 信息隱藏的好處，正好和“封裝”的好處相呼應。封裝是為了提高內聚性；而信息隱藏是為了降低耦合性。通過降低耦合，一樣可以達到提高可復用性、可維護性這2個目的。
具體來說在 電梯調度里的有電梯，乘客，搭乘請求的接口，並將接口封裝到 commons.cs 文件中，在program，elevator，loaders，passenger上就可以方便的使用，而在我們工 作的重點電梯調度算法（scheduler）上，恰當使用這些接口，繼承拓展原來簡單的 scheduler，同時在拓展原scheduler類的同時，我們也充分利用以上方法，拓展員初始化類 和QueueReq類，並將各種判斷條件從主題函數run()中分離出來，方便以后修改復用，例如 ：IsAtTopFloor/IsAtBottomFloor 函數判斷電梯調度邊界條件，LastScheduler定義最近調 度方案，盡可能減少重復代碼。
契約式設計優點
契約能使文檔更出色；契約是類特性的公開視圖中的固有成分；
有着更可靠的文檔，運行時要檢查斷言,以便保證制定的契約與程序的實際運行情況一致；
契約式設計缺點
契約過於死板，不容易讓創意得到實現，也不容易添加新的功能，因為函數功能已經約定好。
我們的方案為每個電梯設置了一個目的地的列表，每個電梯優先去往列表最上的一個目的地。而這個列表的建立，由程序判斷。（1） 在電梯靜止時，若有新的目的地請求時，分4種情況討論：1電梯在提出請求的樓層上方，請求方向向下，則去提出該方向請求的樓層中最近的一層；2 電梯在提出請求的樓層上方，請求方向向上，則去提出該方向請求的樓層中最低的一層；3 電梯在提出請求的樓層下方，請求方向向上，則去提出該方向請求的樓層中最近的一層；4 電梯在提出請求的樓層下方，請求方向向下，則去提出該方向請求的樓層中最高的一層。當沒有新的請求時，電梯請求列表清空，並開往最下一層停留。
（2）在電梯運行時，若是上行，若是中途經過的層中有請求，且方 向一致（即上行），且仍有一人的余量，則該層的上行請求將被接受，電梯到達該層將會停留；同理，當下行時，若是中途經過的層中有請求，且方向一致，且仍有一人的余量，則該層的 下行請求將被接受，電梯到達該層將會停留。