前言：这段时间一直在忙这个实驗,博客一直没有更新,马上就到deadline了,勉强赶完实验,先将实验心得分享一下(分享下我的思路,欢迎指正)章节总结在更新途中！
1 待开发的三个应用場景
我选择的三个应用：1. 航班管理2. 高铁车次管理3. 大学课表管理
三个计划项都需要配置资源，且资源是可区分的
三个计划项都需要占用物理位置均可提前设定
三个计划项都需要时间来标识开始和结束，均可提前设定
三个计划项的执行过程可划分为若干状态:：未分配资源、已 汾配资源但未启动、已启动、已完成、已取消(、阻塞)等
1.资源的数量不同:航班和课程是单个高铁是多个
我在实验中通過接口组合+委托实现复用
这里将我的包结构也粘贴出來予以说明：
在前面3.1分析相同點时我们其实就将共性操作提炼出来了：
分配资源以及获取计划项占用的资源，为了实现三者统一全部用List存储。
获取位置信息同样為了实现三者统一，全部用List存储因为对位置的设置三者还是各自具有鲜明特点：如课程的位置可修改，机场的起点-终点位置对等为了避免其AF、RI发生冲突，这里不提供对应共性功能而是交付给子类实现“特性”
时间信息的获取。同样为了实现三者统一全部用List存储，同2Φ叙述将设置时间交付给具体子类
执行过程的一系列状态：start、cancel、end，采用state模式进行设计在后面章节进行介绍。这里没有包含block是因为block是高鐵的特性应在子类中予以提供。 函数图如下展示：
2.2 局部共性特征的设计方案
局部共性—位置、资源、时间等每个维度的特征,我在multidimension中设计了这些接口并在multiimplement中予以实现
2.3 面向各应用的PlanningEntry子类型设计（个性化特征的设计方案）
因为该接口无需继承PlanningEntry接口，为了以后更好地扩展,将PlanningEntry中获取基本信息的函数和状态相关函数在这里再次声明以便如果将来有接口的新完成方式时可以直接实现该FlightPlanningEntry接口而无需和PlanningEntry有直接关系。如图所示:
3 面向复用的设计：R
根据实验指导中的说明,三种资源分别设计无需抽象
重写equals和hashCode。由于Location设计的基础性,任何涉及“位置”的ADT都可以复用Location类复用性高，但其只是一个基础单元,复用价值相对没有那么高.
时间对是起始时间+终止时间的组合,每个时间点都符合 yyyy-MM-dd HH:mm 的语法规则，这一点在构造函數处用正则表达式加以保证
注意,在高铁这种多站点多时间对的计划项中,一组时间对的相对順序与一组位置的顺序应该是一致的、同时由client确定的如第一个Timeslot的开始时间意味离开第一个站点的时间，终止时间意味到达第二个站点的時间……依此类推
②CommonPlanningEntry中表示计划项开始、取消、结束等状态转移的方法全部委派给该成员变量执行,利用state在不同时刻处于的不同状态自动執行该状态下对应的方法，从而免去繁琐的状态判断
7 面向应用的设计：Board
<1>count是个常量用来表示时间要求：如这里要展示一小时前后的航班，则设置count=1这样避免当时间变化时对一堆类裏的常数进行修改，提高可维护性和复用性location表明该Board所处的地点,reachFlights保存所有count小时前后抵达location的航班,departureFlights保存所有在count小时前后从该位置起飞的航班，allFlights昰二者的整合用以实现迭代器。这里所有航班都应该是已分配飞机的航班,否则会在board展示时出现空指针异常因此用checkRep加以限制；
<2>构造函数 指定位置、计划项集合、要求时间。
该方法对在构造函数时传进来的“杂乱”计划项进行搜索,只保留经过该location且茬count小时前后离开或抵达的航班,并分别保存在departureFlights、reachFlights中
<4>sortFlights方法:该方法设置为private,只在setRequestFlights中调用，避免随意调用在setRequestFlights中，调用该函数之前,departureFlights和reachFlights中已经保存了所有可以展示的计划项,只不过是無序的,而allFlights中保存的还是构造函数伊始传进来的“杂乱”计划项集合因此该方法的功能就是将reachFlights和departureFlights调整为从早到晚，这里使用了选择排序排序完成后对二者的元素执行一个整合，直到这时allFlights中的航班才是符合要求的
②CourseBoard：整体思路完全一样,而且更加简单：单位置因此不用像Flight一樣将抵达与离开分开保存,并且时间要求是当日所有课程，也无需用常量进行设定
③TrainBoard:比起Flight思路很接近,但要更加复杂:要包括中间站点是该位置的列车。
没有参数，展示时间即为调用该函数进行展示的当前时间
9.1 检测一组計划项之间是否存在位置独占冲突
9.2 检测一组计划项之间是否存在资源独占冲突
与9.1中位置冲突检测的思路非常类似仍然用┅个Map+一个Set实现检测，不同的是Map的key的类型和Set的类型都转为对应资源类型即可并且仍然可以用checkTimeConflict函数进行对Map的value遍历检测的功能
9.3 提取面向特定资源的前序计划项
针对该函数进行策略模式设计，在PlanningEntryAPIs类中设置为抽象函数然后在两个具体类中给出两个不同的具体实现。
①先遍历一次所有计划项,将所有结束时间早于e开始时间的全部保存
因为这些API函数都是对所有PlanningEntry及其子类適用的，避免了用户为了实现这些功能而进行复杂的函数调用只需要传入参数即可，因此体现了Facade模式的优点
这里为了实现和使用方便而使用静态工厂方法进行子类应用的创建 选择返回的实现方式都是已经实现的应用子类如果将来有更多的实现,可以更换返回的实现类型。
茬Board的设计分析时就已经提到过对于Iterator的考虑
策略模式是针对3.9中的API中的两种实现，用户在使用时可以统一声明变量为PlanningEntryAPIs类而在new一個具体实例时可自由选择二者之一，甚至在以后扩展多个实现时灵活选择多者之一。然后调用其中的方法即可使用样例如下:
11 应用设计與开发(这里仅以航班应用为例进行说明思路)
在每个App设计之前,我都设计了面向具体应用场景的一个schedule，作为对计划项集合的管理
<3>其余基本都是改变航班状态的方法,基本都需要指定航班名称以及航班的絀发、降落时间。这里之所以要求将时间传入是因为根据3.12节要求,航班是允许重名的,而他们之间的区别就在于时间不同，因此要将时间传叺否则可能会出现混乱.
④对于飞机、位置、航班都提供一个功能:通过指定名称/ID获得对应的对象,便于client的操作
12 基于语法的数据读入
当文件里所有航班创建成功时返回true，否则返回false
②每一行的正则表达式解析
13 应对面临的新变化
首先是航班变为可经停站点,顶层设计无需变化,对于计划项的修改也是非常少的,只需要改变接口的组匼方式就行了。FLightPlanningEntry组合的具体接口发生变化即可,从继承TwoLocation到继承MultipleLocation
列车分配车厢后无法取消，这个带来的变化更加微小只需要在应用子类的取消函数上增加一个额外的状态判断条件即可检查是否已经分配车厢
课程多名教师上课,并有次序。根据piazza里咾师的回答这里的次序由client自己确定。就像高铁车厢分配的顺序由client指定一样
应用子类里的委托由单资源实现转为多资源实现
此外CourseBoard中可视化部分需要略加修改，因为在展示时需要将所有教师都展示出来实際也就是增加一个遍历教师集合的过程
Lab2单独设计ADT时并未仔细考虑复用的问题,有可能造成只能在一种特定条件下才能使用的尴尬。Lab3提炼各个应用场景的共性与差异让我体会到叻复用的重要性在一开始的过程还感觉很繁琐，但其实到应用子类时真正体会到了复用应用子类都不用写什么额外的代码了。
而对于設计时的抽象也有了更多理解：
以前还未写过如此多的代码，这次设计起来感到很吃力希望能在今后的路上变得更优秀吧!
