Lab3總結
設計模式
在實驗中，主要采用了方案5，多處使用委托機制；實驗中主要使用了Strategy、Facade、State模式，這個實驗的主要設計部分應該就是設計模式的部分，其他部分就不贅述了
State模式
entryState部分采用State模式，關系圖如下
每個特定的State狀态(如WaitingState)均繼承于State類，State是一個定義了一些方法的抽象函數，每個子類實作其抽象函數，上圖中的getState()方法不是抽象的(容易看出圖中空心的部分都是抽象的)。枚舉類EntryState包含WAITING、ALLOCATED、RUNNING、ENDED、CANCELLED、BLOCKED等多種狀态。在具體的計劃項中，将與狀态變化有關的方法委托給具體的狀态類來實作
Facade模式
筆者對facade模式的了解是用戶端提供指定的幾種字元串中的一種，程式對不同的輸入字元串采取不同的行為，以達到簡化用戶端使用的目的。在本實驗中，PlanningEntryAPIs要求使用Facade模式，其實筆者認為不需要Facade模式。**以下内容請酌情觀看，筆者隻是提供了一種想法，不保證正确。**老師在一次實驗課中說PlanningEntry應該提供一個傳回資源項的方法(還有地點、時間的方法)，而對于不同的具體Entry，計劃項的資源個數并不相同(地點和時間也是如此)，那麼PlanningEntry傳回資源項的方法應該要傳回一個包括所有資源項的List，為此CommonPlanningEntry中需要包含3個List分别表示資源、地點和時間，在實驗中筆者也是如此實作的。這就造成了一個問題，資源項(地點和時間)在多處實作了，比如FlightEntry，在FlightEntry中有一個SingleResourceEntryImpl的執行個體，該執行個體中有一個代表Resource的資料成員，而在其父類CommonPlanningEntry中已經存在一個List存儲資源了。為了防止空間浪費和程式出錯，筆者将兩處的實作都指向了同一位址，隻要修改其中一個，另一個因為指向同一位址自然也被修改了。
說了這麼多，就是想說明不用Facade模式也可以。因為CommonPlanningEntry裡已經有資源、地點和時間的List，也不需要區分用戶端希望用的是哪個具體計劃項，在此給出筆者檢查不可共享位置沖突的實作，其中entries是之前輸入的一組計劃項(代碼說不定寫錯了)
其他倆也差不多
Strategy模式
筆者的了解是，給用戶端提供多種實作相同目标的不同政策，讓用戶端在使用時進行選擇。為了讓筆者的實驗看上去确實用了Facade模式，筆者為CheckLocationConflict方法提供了另一種實作：基于Facade模式的實作有點掩耳盜鈴的感覺。具體直接看圖吧