哈工大软件构造lab3实验心得（二）——实验思路

简述

承接上一篇博客，这篇是关于lab3的实验思路的，也就是我是如何一步一步思考，最终完成lab3的。话不多说，先上表。

总体任务

通读lab3实验手册之后，我将总体任务划分为如下几块：

• PlanningEntry部分
• Board部分
• API部分
• APP部分
• 314Change

同时，手册建议/要求我们在某些地方使用一些设计模式，包括：

• 在实现个性化特点时使用装饰器模式
• 在实现状态转变时使用状态模式
• 在设计API时使用外观模式
• 使用工厂方法模式来创建具体的计划项对象
• 使用迭代器模式为Board类增加迭代器
• 设计API时使用策略模式，便于Client切换实际算法

依据我lab2实验心得给出的设计过程：

确立UML类图模型--->写好每个类的AF、RI与方法的spec（这一步需要花费很多时间，但是尤为重要）--->写Junit测试用例--->填代码

我将据此逐步展示我当时的思路。

确定UML类图模型

• 原则

面向接口设计、以便于Client调用。这里的Client是广义的，不仅仅包括直面用户的客户端、也包括想要使用某个类的调用者，也视为Client。

• 抽象出各个类

首先根据手册要求大致将需要的类划分一下：

1. 实验手册已经帮我们确定了一些类：Resource、Timeslot、Location、State、PlanningEntry、CommonPlanningEntry
2. 因为我选择实现的是航班、高铁、活动
   所以自然地又抽象出3个类：FlightEntry、TrainEntry、ActivityEntry
3. 实现Board功能的类
4. 实现API功能的类
5. 需要APP类将所有功能综合到一起，并提供给Client接口，以方便调用

接下来需要根据实际需求更近一步地细化抽象：

• 首先手册中要求我们对PlanningEntry进行泛型化处理，用R表示泛化资源类型，表现为PlanningEntry<R>
  关于泛型的使用详解，大家可以参考下面的这篇博客：
  这是来自csdn的一篇关于泛型用法的博客，总结地很全，可以点击查看

• Resource类
  表示计划项所使用的资源，不同的计划项资源也不同，但都是Immutable的，所以我就将Resource设计成一个Interface，然后再设计三个具体实现类：Plane、Train、Material。这样便可满足要求了，而且可以直接用Resource来具体化PlanningEntry<R>中的R

• Timeslot类
  因为三个计划项都会用到时间段，所以我们直接用一个Timeslot类来表示即可，并设计成Immutable

• Location类
  与Timeslot类相似，直接用一个Location类来表示地点的概念即可，也设计成Immutable

• PlanningEntry类
  根据面向接口设计原则，我首先将PlanningEntry设计成Interface；
  再根据本篇博客开头的那张表可见这三个计划项有部分共同点、也用部分特性，所以我将CommonPlanningEntry设计成具体计划项类的共同父类，并实现Plann