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模式的实现有点掩耳盗铃的感觉。具体直接看图吧