HIT2020 软件构造lab3心得体会
[软件构造] 07 软件构造lab3心得体会
每年哈工大软件构造课的lab3都是重中之重，难度和任务量都相当的大，主要体现在设计方案的多样性和自由选择性，多种设计模式的应用，繁杂的单元测试等等。但自己真正认真完成下来收获还是巨大的，不仅能够对不同设计模式进行实践，还能够体验到软件构造中的可复用性和可维护性的重要性。
软件构造lab3心得体会
- [软件构造] 07 软件构造lab3心得体会
- 1. 实验任务简述
- 2. Planning Entry的设计方案
- 3.实验中用到的设计模式
- Factory Method
- Iterator
- Strategy
- 4.正则表达式的运用
- 5.写在最后
1. 实验任务简述
实验3要求设计并实现一个抽象数据类型Planning Entry，对现实中各类利用特定资源、在特定地点/位置开展的一项任务进行抽象，并在五个具体应用中使用它。
实验要求需要完成的应用为：1 必做、2 和 3 任选 1 个、4 和 5 任选 1 个。也就是说，至少要完成 3 个应用：1 and (2 or 3) and (4 or 5)。
- 航班管理
- 高铁车次管理
- 操作系统进程管理
- 大学课表管理
- 学习日程管理
整个Planning Entry的设计都是围绕这下面的这一张表来进行的。
2. Planning Entry的设计方案
实验指导书上给出了较为详细的6种实现方案。方案一、二、三的缺点显而易见，故可选的方案实际只有3种。方案四通过继承树实现多维度上的不同取值的方案，仅在五个维度上就会产生组合爆炸的情况，而在将来可能增加不同的维度和变化的情况下，会出现很差的可维护性和可复用性。
而对于方案六使用decorator设计模式，我在博客中对这种设计模式的结构和适用情况进行了详细的分析。因此认为强行使用这种设计模式并不合适。
综上所述，我认为方案五是实现PlanningEntry类及其子类型的一个比较好的方法，既保证了可复用性和可维护性，又一定程度上地避免了代码重复，而且实现起来相对简单。
方案五：CRP(Composite Reuse Principle)，通过接口组合及delegation委托实现局部共性特征的复用。
以FlightEntry为例，我设计的实现方案的UML类图如下图所示，另外还需要设计TrainEntry和CourseEntry，实现方案与FlightEntry类似。
3.实验中用到的设计模式
实验中涉及到的设计模式有Decorator,Facade,Iterator,State,Factory Method,Strategy这六种设计模式，而在这门课程中讲述的设计模式总共有十三种，我打算在下一篇博客中对课程涉及到的这十三中设计模式进行一个总结，同时也方便自己的复习。(虽然也不知道什么时候开学和期末考试)
Factory Method
通过在PlanningEntryFactory类中设立创建接口，然后在它的每个子类型中定义具体要创建哪一个实体的产品类。对应于三个不同的应用，分别有三个子类型的工厂分别创建出三个不同的计划项，避免了通过new的方式实例化具体的PlanningEntry的子类型。这样在类需要扩展时，只需要修改具体的工厂类中的创建方法，将变化的部分和不变的部分分隔开来，避免了客户端的改变，提高了可维护性。
Iterator
这个设计模式的使用主要是用来以统一的方式遍历Board类中的计划项集合，可以看作是策略模式在遍历访问对象中的应用，为了实现简单，我并没有自己写遍历的代码，而是通过委托给List的Iterator，让它来实现遍历，我猜测老师的目的应该主要是让我们能够熟练的掌握各种设计模式的结构和应用。
Strategy
对于之前的API设计中的checkLocationConflict方法，我采用策略模式进行实现，对检测位置独占冲突采用了两种不同的算法，一种算法正是前面所说的分别选定每个计划项，从前往后进行冲突检测，而我实现另一种算法则是从后往前不断进行检测。这样客户端在调用时就可以根据不同的性能和实现要求选择不同的算法。但在我的这个策略模式中的两种策略其实本质区别并不大，因而主要是为了练习策略设计模式，通过实验对它进一步熟悉和理解。
4.正则表达式的运用
正则表达式的练习使用也是lab3实验的一个比较有趣的地方，通过对给定的配置文件的信息进行解析，在app中实现从外部文件读取数据。
正则表达式在计算机的各个方面应用真的非常广泛。就拿这学期的课程来说，《形式语言与自动机》通过从理论的方面来研究正则表达式的结构，性质和设计等，而《软件构造》通过从Java中的正则表达式应用来通过代码进行使用，这两门课程分别从理论和实践的角度对它进行了介绍和使用，做到了理论与实践有机结合，将理论付诸于实践。
其中要求解析一条航班计划项的文件格式如下所示。
Flight:2020-01-16,AA018
{
DepartureAirport:Hongkong
ArrivalAirport:Shenyang
DepatureTime:2020-01-16 22:40
ArrivalTime:2020-01-17 03:51
Plane:B6967
{
Type:A340
Seats:332
Age:23.7
}
}
这是我书写的正则表达式的代码，
String[] strings= {
"Flight:(?\\d{4}-\\d{2}-\\d{2}),(?[A-Z]{2}\\d{2,4})"
, "\\{"
, "DepartureAirport:(?\\w+)"
, "ArrivalAirport:(?\\w+)"
, "DepatureTime:(?\\d{4}-\\d{2}-\\d{2} \\d{2}:\\d{2})"
, "ArrivalTime:(?\\d{4}-\\d{2}-\\d{2} \\d{2}:\\d{2})"
, "Plane:(?(N|B)\\d{4})"
, "\\{"
, "Type:(?[a-zA-Z0-9]+)"
, "Seats:(?\\d{2,3})"
, "Age:(?(\\d|[1-9]\\d)(.\\d)?)"
, "\\}"
, "\\}"};
5.写在最后
lab3实验给定的时间是五周，而在实验中用到的课程知识也都是在这五周之内逐渐讲授的，因而就会出现实验要编写的代码依赖于还没有讲述到的课程，这种情况极大地提高了自学能力。例如：lab3的中前期需要应用到State设计模式来设计状态，但是该设计模式却是在实验周期中的第4周才讲述到的，因而想要完成实验只能够尽可能早地去自学，否则的话在设计三个app，board的GUI设计，和各种单元测试的这三个硬核的近两千行的代码的压力下根本不可能完成。
CSDN上有大佬好像在实验发布的第一周内就完成了lab3的实验和验收，还有的大佬app的设计采用的是GUI设计（近5000行代码,相当华丽），而像我这样的菜鸡也只能够将Board设计成GUI，而app采用命令行的方式来进行实现。这些都让我深深地感慨到"路漫漫而修远兮，吾将上下而求索"，自己和大佬之间的差距还是巨大的，还需要不断的努力。