航空器配载与货运管理系统大作业总结

前言部分：

总结知识点：

• 首先设计基础类的设计原则：单一职责原则。然后由于是迭代式的作业形式，前期对于类的设计，类之间的耦合度就要把控好，迭代的时候就不会粘度过高。
• 其次学习了常用的Arraylist的集合容器。同时复习了基本的两种排序方法。然后学习开发时要注意满足封装性、可扩展性的要求。
• 然后是我个人的见解，作为这种有输入输出的，我们可以直接封装一个IO类来处理我们的数据接收和结果输出，对于输入的数据我们还可以再封装一个数据中心（dateBase）来统一的管理数据。（这里也可以再加一个简单工厂模式对于具体创建对象我不直接在IO中的Input中new出，而是做一个工厂类来代替我创建对象的语句，返回我实际需要的对象而不显示其实际创建过程）

题量：

我认为前两个是比较容易实现的，因为类比较少，然后功能也比较简单，但是最后一个就比较麻烦了，具体加入了非法输入的检测和力矩的计算，然后引入实体类没什么关系，但是引入了专门的计算类就要考虑更多了，然后计算类和Flight类是依赖关系，也就是只能是传参数的形式而不是直接作为其成员变量的关联。

难度：

难度显而易见是随迭代成上升趋势的，然后最后一个比前两个上升的难度跨度比较大

设计与分析：

第一次迭代作业的类图如下：

解释设计：

• 实体类Cargo作为货物类，有其货物名称、重量，然后为了方便后面排序，我在这个类中写了一个类的比较，参数是与当前类比较的类。然后是货物重量和名称的get方法
• 然后是中转类，LoadManifest,主要处理的是添加货物，然后对于货物集合可以做一个排序，所以这里的CargoSort就是调用CargoSotter的排序方法，为了方便后面计算总货物质量，我在这里写了一个获取货物总重量的方法。这个类的成员变量就是货物集合,泛型为Cargo和总的重量。
• 实体类Flight，航班类，成员变量为航班编号、最大装载重量、Loadmanifest货舱类，然后就是这三个的get方法和货舱的set方法。
• IO类成员变量为Scanner sc，这个类就是用来处理输入输出的，Input返回航班对象，Output接收参数航班对象，然后根据要求输出。
• main程序入口，只有IO类，调用其Input和Output实现数据输入和输出结果。

心得：

• 注意这里的sort方法，到第二版的时候我的排序调用的位置已经完全变形了，这里挖个坑到第二次迭代作业再做解释
• 这里的Flight是直接作为IO的成员变量的，本来IO只是一个处理输入输出的一个类，但是这里却把其和主要的航班类耦合在一起是不合适的，更优雅的做法应该是依赖关系。
• 这里还有一个小小的算法知识，也算是数据结构的一个知识点，但是也会成为一个WA点，因为选择排序是不稳定的，由此可以推断出如果采用选择排序会改变原来相等的数的有序性。

第二次迭代作业的类图如下：

解释设计

• Cargo类：成员变量为货物的名字、编号、重量然后分别是这三个的get方法。
• Position类：成员变量为行数和列数，然后获取位置的名称，也就是哪个货舱的某个位置，这里的Position类构造出来确确实实是没有一点作用的，不知道构造出来这个啥意思，然后后面第三次迭代也没有用到
• CargoCompartment类：货舱类有id、最大载货重量、货物集合、然后是毫无作用的位置集合。和上一个版本一致都有添加货物的方法、和获取重量、id、最大装载重量、货物集合。
• LoadDispatcher类：排序货物集合的方法和找到某个位置的货物方法。
• Flight类：航班类，有航班号、最大起飞重量和最大载重重量、由于可能后面有多个货舱，所以此处还是一个货舱的集合作为航班类的成员变量。剩下的全是对应的成员变量的get方法。
• dateBase类：成员变量为航班类和一个货物集合，然后是他俩的获取方法。然后这里的设计非常不合理，在心得我会重点写这里。
• InputValidator类：是检验输入是否合法的类，这是为第三次迭代做准备，这里没有任何作用，然后我还是把这个耦合在了IO类中
• IO类：成员变量多了个inputValidator对象，用来检验输入是否正确。然后这里我的Flight不是直接耦合在IO中了，因为在一个包里可以直接构造其对象，所以我直接在Input创建对象了，结束返回接收创建好的datebase即可。
• Main类：还是一样作为程序入口，只有一个IO对象

心得:

• 首先是我在数据中心那里的处理，是十分混乱的，我在数据中心中直接耦合一个货物集合是因为，这个测试只会有一个货舱，完全没有考虑到后面的扩展性。然后我为了处理方便，直接在数据中心中实现货物集合的排序，然后再把其放到Flight类中的货舱类的货物集合，职责分的十分混乱，职责划分也错误。
• 对于上面问题的解决我的方案是像上一代一样，在每个货舱中维护一个方法，可以直接给本货舱中的货物集合进行排序。
• 然后这个版本还是直接在IO的Input中接收数据输入直接new出对象，更优美的处理方式是简单工厂模式，然后不要在创建实例对象的时候不要显现其具体创建过程。
• 然后接下来说一下我这道题的WA点，这个不能完全怪我，但是也是符合实际开发的情况，是应该猜到这样的情况，是输出的时候，题目给出的输出格式是带"(超载)"，但是实际输出案例是没有这个子字串的。

第三次迭代作业的类图如下：

解释设计：

• 实体类Cargo：货物类有货物名称，货物编号和其重量，与前两次一样的方法
• Luggage：行李类，只有重量，然后还有get方法
• Passenger：乘客类，有其名称重量和行李，所以这里的行李是直接耦合在乘客中
• CargoCompartment:货舱类，和之前一致的成员变量：最大载重、货物序列、位置序列。
• Flight：飞机类，迭代在原先基础上新增了乘客序列。我这里为了处理清晰方便，我在飞机类中直接能够获取乘客的总重量和货舱的总重量。由于我的排序已经在第二次迭代的时候乱了套，所以这里我又加了设置货舱的方法，也就是说这里的货舱已经在航班中完全破坏了封装性。然后我这里又重新把航班列表加了上去。
• InputValidator：输入检测类，这里导致了一个巨大的坑后面再说，然后我直接把Scanner对象直接放在了这里，所以所有接收的输入都在InputValidator中进行，然后检测输入的问题也是在这里进行。
• WeightBalanceCalculate：包含所有的力矩的计算然后包含了所有要用到的静态常量。
• IO类是如上一版本一致的处理输入输出，但是这一版的改进就是不直接处理输入而是把职责分给输入检测类。
• main类是程序入口，但是耦合的是IO和dateBase原因是我这里改进时想到，IO不应该之和这个系统的输入相关，应该是统配所有接收输入和输出。所以和接收数据类之间是依赖关系

心得：

这个版本的wa点就非常多了：

• 首先第一次的提交是一个测试点都没过，原因是我没有处理非法输入的输出，导致所有的测试都错了
• 第二次提交是因为这里p的范围错误，我误以为就是[0,m]，但是实际上是[1,m],所以一篇盖全全以为输入都是大于0即可。
• 第三次提交，题目描述采用冒泡排序，但是我实现排序并调用后结果答案错误，但是我把排序功能删除后结果答案正确，原因未知

然后总结一下知识点，以及改进方案

1. 通过这几次迭代作业首先就是对于单一职责原则的理解更加深入，然后对于耦合度，整体的粘度更加了解，开发中更应该是粒子化的类来构建起来。
2. 理解需求也很重要，往往我们应该在看到模糊的描述的时候要特别留意这个位置，很可能就是后面需要再次确认的点，也符合实际的开发中用户需求的不确定性，要求留意模糊需求位置。
3. 然后就是提到我没有改进好的地方，其实我完全可以把排序的调用放在飞机类的生成中，在放入货舱给飞机类的构造方法时候就直接调用排序的静态方法，然后后序就不用再管排序的问题了。
4. 可以应用的方案是简单工厂模式，对于输入我是直接在Input中创建具体对象，但是实际创建对象的过程不应该在接收输入的地方，以为我只要这样的一个对象，而不是看到这个具体的构造过程。
5. 然后注意扩展性和封装性，我不应该是因为结构的问题，而去直接破坏封装性，这样不利于后面再扩展
   下面按顺序给出我三次作业的代码复杂度