题目集8~9的总结性Blog

前言

面向对象程序设计课程第二次迭代设计作业结束了，第二次迭代作业，以航空货物管理系统为中心，不断的添加新的功能，在这个过程中有许多的知识点。
1.Java基本语法；
2.Java容器类的使用；
3.Java的继承和多态
4.面向对象的设计思路；
5.如何增加代码可拓展性；
6.如何使用自动化测试工具。
这两次的题目集的题目量不大，难度适中，对于算法的考查不是很大，主要考查对于类的构造等知识点。只要题目集8中的航空货物管理系统的类设计好以及代码的扩展性好，那么题目集9中的迭代难度降低的很多。

设计与分析

第一次跌代作业

作业要求

某航空公司“航空货运管理系统”中的空运费的计算涉及多个因素，通常包
括货物重量/体积、运输距离、附加费用、货物类型、客户类型以及市场供需等。
本次作业主要考虑货物重量/体积，以下是具体的计算方式和关键要点：
一、计费重量的确定
空运以实际重量（GrossWeight）和体积重量（VolumeWeight）中的较
高者作为计费重量。
计算公式：
体积重量（kg）= 货物体积（长×宽×高，单位：厘米）÷6000
示例：
若货物实际重量为80kg，体积为120cm×80cm×60cm，则：
体积重量 =(120×80×60)÷6000=96kg
计费重量取96kg（因96kg>80kg）。
二、基础运费计算
费率（Rate）：航空公司或货代根据航线、货物类型、市场行情等制定（如
CNY 30/kg）。本次作业费率采用分段计算方式：

公式：基础运费 = 计费重量 × 费率
三、题目说明
本次题目模拟某客户到该航空公司办理一次货运业务的过程：
航空公司提供如下信息：
航班信息（航班号，航班起飞机场所在城市，航班降落机场所在城市，航班
日期，航班最大载重量）
客户填写货运订单并进行支付，需要提供如下信息：
客户信息（姓名，电话号码等）
货物信息（货物名称，货物包装长、宽、高尺寸，货物重量等）
运送信息（发件人姓名、电话、地址，收件人姓名、电话、地址，所选
航班号，订单日期）
支付方式（支付宝支付、微信支付）
注：一个货运订单可以运送多件货物，每件货物均需要根据重量及费率单独
计费。
程序需要从键盘依次输入填写订单需要提供的信息，然后分别生成订单信
息报表及货物明细报表。
四、题目要求
本次题目重点考核面向对象设计原则中的单一职责原则、里氏代换原则、开
闭原则以及合成复用原则，除需要在PTA平台提交源码外，还需要在超星平台
提交本次作业最终得分源码（首次提交最高分源码）的类图，评判标准为：
基础得分：PTA实际得分
设计因素：单一职责原则（40%）、里氏代换原则（20%）、开闭原则（20%）、
合成复用原则（20%）
最终得分：基础得分扣减所有违背设计原则分值（违背所有四个原则的设计
最终得分为0分

实现方式

主类通过控制台依次读取客户、货物（含数量及长宽高、重量等）、航班（含载重）、订单、发件人、收件人信息，创建对应对象。控制类计算货物总重量与总价，先校验是否超航班载重，未超则按客户、航班、订单、收发件人顺序展示信息，再输出总重、微信支付金额及货物明细（含计费重量、费率、运费），实现数据整合与业务逻辑处理。

源码分析

代码类图

设计了10个类
Main类：主类从控制台读取客户、货物、航班、订单、收发件人信息创建对应对象，传入Control对象并调用show方法显示订单信息。
Control类：含计算总价、总重方法，show方法校验载重，未超则展示多类信息、总重、支付方式及货物明细。
Customer类：表示客户，包含客户编号、姓名、电话和地址等信息，并提供了显示客户信息的方法。
Flight类：表示航班，包含航班号、出发机场、到达机场、日期和载重等信息，并提供了显示航班号的方法。
Sender类：表示发件人，包含地址、姓名和电话等信息，并提供了显示发件人信息的方法。
Recipient类：表示收件人，包含地址、姓名和电话等信息，并提供了显示收件人信息的方法。
Order类：表示订单，包含订单号和日期等信息，并提供了显示订单号和日期的方法。
Goods类：表示货物，包含货物编号、名称、宽度、长度、高度和重量等信息，并提供了计算体积重量、实际重量、计费费率和价格的方法。
Payment类：该类是支付方式的父类，包含支付金额，并提供了一个抽象的pay方法。
Alipay类和WechatPay类：这两类是Payment类的子类，分别实现了支付宝支付和微信支付的pay方法。

复杂读分析

代码规模：代码行数为422行 ，涉及多个类（如Flight、Customer、Sender、Recipient、Order、Goods、Payment及其子类、Control、Main等 ）。围绕物流订单管理系统展开，涵盖航班、客户、订单、货物等信息管理及支付功能。

复杂度：最大复杂度为2（位于Main.main() ） ，平均复杂度为1.11 ，分支语句占比3.2%，方法调用语句有55个 。整体逻辑分支较少，但方法间存在一定调用关系，如Control类中方法调用其他类的方法获取信息，有一定理解和维护成本。

注释情况：带注释的行数占比2.4% ，注释比例极低，严重影响代码可读性，难以快速理解代码业务逻辑和算法思路。

优点：功能模块划分较细，不同类分别负责航班（Flight类）、客户（Customer类）、货物（Goods类）等相关信息管理，职责相对明确。实现了物流订单管理从信息录入到费用计算、订单展示等较为完整的流程，功能具有一定完整性。

不足：注释极度匮乏，像Goods类中复杂的费用计算逻辑、Control类中校验载重及展示信息逻辑等关键部分无注释说明，理解和维护难度大。部分类的属性和方法命名不够规范统一，可能导致阅读和使用时混淆。代码中支付方式仅简单实现微信支付等，扩展性欠佳，难以快速添加新支付方式。

心得：代码行数较多，通过多类实现物流订单管理功能。虽功能模块有划分，但复杂度管理一般，注释过少影响可读性。功能较完整但代码质量方面存在不足，如注释缺失、命名不规范、扩展性差。这提示编程时要注重代码规范，增加有效注释，提升代码扩展性，平衡功能实现与代码质量。

第二次迭代作业

作业要求

某航空公司“航空货运管理系统”中的空运费的计算涉及多个因素，通常包
括货物重量/体积、运输距离、附加费用、货物类型、客户类型以及市场供需等。
本次作业主要考虑货物重量/体积，以下是具体的计算方式和关键要点：
一、计费重量的确定
空运以实际重量（GrossWeight）和体积重量（VolumeWeight）中的较
高者作为计费重量。
计算公式：
体积重量（kg）= 货物体积（长×宽×高，单位：厘米）÷6000
示例：
若货物实际重量为80kg，体积为120cm×80cm×60cm，则：
体积重量 =(120×80×60)÷6000=96kg
计费重量取96kg（因96kg>80kg）。
二、基础运费计算
费率（Rate）：航空公司或货代根据航线、货物类型、市场行情等制定（如
CNY30/kg）。本次作业费率与货物类型有关，货物类型分为普通货物、危险货
物和加急货物三种，其费率分别为：

计算公式：基础运费 = 计费重量 × 费率 × 折扣率
其中，折扣率是指不同的用户类型针对每个订单的运费可以享受相应的折扣，
在本题中，用户分为个人用户和集团用户，其中个人用户可享受订单运费的9
折优惠，集团用户可享受订单运费的8折优惠。
三、题目说明
本次题目模拟某客户到该航空公司办理一次货运业务的过程：
航空公司提供如下信息：
航班信息（航班号，航班起飞机场，航班降落机场，航班日期，航班最大载
重量）
2
客户填写货运订单并进行支付，需要提供如下信息：
客户信息（姓名，电话号码等）
货物信息（货物名称，货物包装长、宽、高尺寸，货物重量等）
运送信息（发件人姓名、电话、地址，收件人姓名、电话、地址，所选
航班号，订单日期）
支付方式（支付宝支付、微信支付、现金支付）
注：一个货运订单可以运送多件货物，每件货物均需要根据重量及费率单独
计费。
程序需要从键盘依次输入填写订单需要提供的信息，然后分别生成订单信
息报表及货物明细报表。
四、题目要求
本次题目重点考核面向对象设计原则中的单一职责原则、里氏代换原则、开
闭原则以及合成复用原则、依赖倒转原则，除需要在PTA平台提交源码外，还
需要在超星平台提交本次作业最终得分源码（首次提交最高分源码）的类图，
评判标准为：
基础得分：PTA实际得分
设计因素：单一职责原则（20%）、里氏代换原则（20%）、开闭原则（20%）、
合成复用原则（20%）、依赖倒转原则（20%）。
最终得分：基础得分扣减所有违背设计原则分值（违背所有五个原则的设计
最终得分为0分）

实现方式

该Java代码构建物流订单管理系统。主类从控制台读取客户（依类型创对应对象）、货物（依类型创对应对象）、航班、订单、收发件人及支付方式信息，创建对应对象。Order类计算总价、总重并处理支付。Show类校验载重，未超则展示客户、航班等信息及货物明细，实现订单信息管理与展示。

源码分析

代码类图

Main类：主类从控制台读取客户、货物、航班、订单等信息，创建对应对象，将其传入Show对象，调用show方法显示订单信息。
Order类：订单处理类，TotalPrice算总价并依客户类型用折扣，setPayment依支付方式创对象，pay调用前者执行支付，TotalWeight算货物总重。
Show类：show方法首先检查货物总重量是否超过航班载重，如果超过则输出提示信息；否则打印订单表。
Customer类：Customer类是抽象类，包含客户的基本信息和一个抽象方法getDiscount，由其子类CustomerIndividual和CustomerCorporate实现不同的折扣策略。
Goods类：Goods类是抽象类，实现了Rate接口，包含货物的基本信息和计算体积重量、实际重量、价格的方法，由其子类normalGoods、ExpediteGoods和DangerousGoods实现不同的计费费率。
Payment类：Payment类是抽象类，包含支付金额和一个抽象方法pay，由其子类Alipay、WechatPay和Cash实现不同的支付方式。
People类：People类包含人员的基本信息

复杂度分析

代码分析

代码规模：代码行数为492行，涉及Flight、Customer及其子类、Goods及其子类、Payment及其子类、Order、Show、People等多个类，围绕物流订单管理系统展开，涵盖客户、货物、航班、订单、支付等功能模块。

复杂度：最大复杂度为5（位于normalGoods.setElephone() ），平均复杂度为1.21 ，分支语句占比7.6%，方法调用语句有20个。整体逻辑分支不算多，但存在个别较复杂方法，有一定理解和维护成本。

注释情况：带注释的行数占比2.6% ，注释比例极低，严重影响代码可读性，难以快速把握业务逻辑与算法。

优点：
功能模块清晰：不同类分别负责客户、货物、航班、订单处理等功能，职责明确，如Customer子类区分个人和集团客户折扣策略，Goods子类实现不同货物计费费率，便于理解和维护各功能模块。
扩展性基础好：通过抽象类和接口定义规范，如Customer抽象类,getDiscount抽象方法，Goods抽象类实现Rate接口，便于后续扩展新客户类型和货物类型。

缺点:
注释严重不足：关键逻辑处如订单总价格计算（含折扣应用）、不同货物费率计算等缺少注释，理解和维护困难。
方法命名混乱：部分方法命名表意不清，如多个类中出现setElephone方法，易混淆，降低代码可读性。
代码耦合度较高：类与类之间依赖关系较复杂，如Order类与Goods、Customer、Payment等类关联紧密，一处修改可能影响多处，不利于代码扩展与维护。

心得:
代码规模较大，功能模块划分有优势，但复杂度管理欠佳，注释稀缺。虽有一定扩展性基础，但命名混乱和耦合度高问题突出。这提醒编程时要重视规范注释，合理命名方法，降低耦合度，兼顾功能实现与代码质量，确保代码易读、易维护、易扩展。

踩坑心得

第一次的代码的设计不足，导致代码的扩展性较差，第二次的迭代的作业的代码与第一次的迭代作业的代码相差较大。以及审题不仔细，写代码时出现大量错误以及代码冗杂度大。
第二次的代码由于第一次的迭代作业的代码设计不足，使第二次的迭代的代码修改较多，还有代码的耦合度较高，类与类依赖关系较复杂。
综上我踩过的坑，在写代码之前一定要先构思好代码的结构再动手写。

改进建议

注释补充：添加类注释说明设计目的，为关键方法（如TotalPrice）和业务流程（如载重校验）添加逻辑解释。
结构优化：将Main中的输入逻辑拆分为工厂方法，使用策略模式简化Goods子类的getRate方法。
降低耦合：通过接口（如Rate）减少类间依赖，将Order与具体Goods子类解耦。

总结

物流订单管理系统代码开发颇具挑战且收获良多。开发时务必重视代码设计与架构，合理架构是应对业务变化与功能扩展的基石。需高度关注可读性与可维护性，及时补充注释。对货物重量超限等边界情况及支付异常等状况，处理要周全严密。遇到问题不盲目改代码，深入剖析根源后选恰当方案。每次代码瑕疵都是成长契机，不断复盘优化，方能打造高质量代码。