软件构造 Lab3总结

该实验在代码逻辑上难度不大，不需要设计很复杂的算法，但是代码量巨大，所以需要设计好类与类之间的关系再下手，否则一次次推翻重来非常搞心态， 比如我 。

设计思想

该实验要求在航班管理、高铁车次管理、操作系统管理、大学课表管理、学习课程管理中一必选、二三选一、四五选一，我选择了航班管理、高铁车次管理、大学课表管理。

设计PlanningEntry

用过实验指导书的分析，不难发现，这三个计划项的主要差别在于涉及的资源的类型和数量、位置数量、时间段数量。

由于需要实现面向接口的编程，在接口设计时就需要将需要使用的基本方法都写到，包括但不限于：

• 设置一个计划项；
• 为该计划项安排时间和位置信息；
• 为该计划安排资源；
• 查看计划项状态；
• 查看计划项名称；
• 改变计划项状态；
• 查看计划项涉及的时间；
• 查看计划项涉及的位置；
• ……

私以为只有这样设置才能不在实现Facade设计模式时，出现难以统一接口的窘境，比如我 。而且这样应对314change时就能做到改动很小。

至于该种接口的实现方式有可能导致为某个计划项安排错误数量的资源、位置或时间段的问题，可以将其硬性要求写入RI，然后在调用具体计划项子类时，先checkRep()验证合法性，通过后返回其所需要的内容，否则抛出异常。

设计R

首先，可以提取其共性特征：资源都有唯一编号。
所以可以据此来设计父类，然后在子类中具体实现各资源独有的特征。

设计Location

私以为是常规immutable类的设计，字段包括经纬度、名称、是否可共享，方法包括获取字段各信息即可。

设计Timeslot

也是常规immutable类的设计，字段包括起始时间、终止时间，方法包括获取字段信息。
为了强调时间不可更改的特征，选用LocalDateTime而非Calendar或Date等可变类。

设计模式

在网上可以很容易地找到各设计模式的原理和示例，在这些资料的帮助下，实现指导书所要求的设计模式就变得很简单了，因此不再赘述。

PlanningEntryCollection

一开始没有注意到指导书对于这个类的描述，所以一度很迷惑在设计PlanningEntry接口为一个计划项时，如何整合多个计划项。

这个类主要是为了实现多个计划项的调度安排，与客户端所需要的具体功能密不可分。

由于Location和R都是面向复用设计的，所以在父类的字段里可以声明两个List分别存储Location和R。父类的方法包括加入、删除一个位置，加入、删除一个资源、检查某个位置、某个资源是否被使用、展示信息板等。鉴于资源的多样性，可以将PlanningEntryCollection设置为抽象类，在具体collection类中再实现它们。