第二次BLOG

一.前言本次题目集主要考查了继承与多态两个新内容，系统会根据输入的信息创建相应对象，检查航班载重是否足够，并按要求格式输出订单信息和货物明细。计费重量取实际重量和体积重量的较大值，费率根据计费重量分档计算，其中还加入了抽象类的设计以及对接口的考查，极大程度提高了学生的编程能力，由于只有两次题目，题量适中，难度只存在于迭代重点考查对面向对象特性的掌握，以及数据处理和业务逻辑实现能力，需精准把控各类信息的交互与处理。
二.设计与分析
第一次：

类：
Goods 类：表示货物，负责计算体积重量、计费重量、费率和运费
Flight 类：表示航班信息，包含航班号、起降机场、日期和最大载重
Order 类：表示订单，包含订单基本信息、关联的货物列表，并计算总重量和总运费
Customer 类：表示客户信息
Main 类：程序入口，处理输入输出流程
类关系与功能
Goods 类 是系统的基础单元，负责计算各种与货物相关的费用参数
Order 类 聚合了多个 Goods 对象，负责订单级别的计算
Flight 类 提供航班载重信息，用于判断订单是否可被承载
Customer 类 存储客户基本信息，与订单关联
优点
面向对象设计：采用了面向对象的设计原则，将系统划分为多个职责明确的类（Customer、Goods、Flight、Order），提高了代码的可维护性和可扩展性。
清晰的层次结构：各个类的职责划分清晰，Goods 类负责货物计算，Order 类处理订单相关逻辑，Flight 类管理航班信息，符合单一职责原则。
数据封装：合理使用了 private 访问修饰符和 getter 方法，保护了数据的完整性，外部无法直接修改对象内部状态。
输入处理：使用 Scanner 类处理用户输入，逻辑清晰，能够正确读取不同类型的输入数据。
计算逻辑完整：实现了货物计费重量、费率和运费的计算逻辑，以及订单总重量和总运费的汇总计算。
载重检查：在订单处理前进行了航班载重检查，确保系统逻辑的正确性。
缺点
日期处理不规范：使用 String 类型存储日期，没有利用 Java 的日期时间 API（如 LocalDate），导致日期处理和格式化不方便，也容易出现格式错误。
缺乏异常处理：没有处理可能出现的输入异常（如非法数字格式）或空指针异常，程序在遇到异常输入时可能崩溃。
代码重复：输出格式化部分存在重复代码，如 System.out.printf 语句多次出现，降低了代码的可维护性。
类设计缺陷：
Flight 类没有记录当前已使用载重，无法动态跟踪航班载重状态
Order 类与 Goods 数组直接关联，缺乏对货物列表的动态管理机制
缺乏输入验证：没有对用户输入进行有效性检查（如负数重量、空字符串等），可能导致程序运行异常。
硬编码问题：费率计算逻辑硬编码在 Goods 类中，不利于后续调整和扩展。
输出格式问题：货物明细的输出格式在某些情况下可能对齐不佳，影响可读性。

第二次：

类设计与代码分析
类结构与关系
Goods 类：
核心属性：货物 ID、名称、尺寸、重量及费率策略
核心功能：计算体积重量、计费重量及运费
设计亮点：通过策略模式解耦费率计算逻辑
Flight 类：
核心属性：航班号、起降机场、日期、最大载重及当前载重
核心功能：动态管理航班载重状态，提供载重检查方法
Order 类：
核心属性：订单基本信息、关联货物、航班及客户
核心功能：计算订单总重量、总运费，处理支付方式转换
Customer 接口与实现类：
接口定义：客户基本信息及折扣率计算方法
实现类：个人客户（9 折）、企业客户（8 折），体现多态性
RateStrategy 策略接口与实现：
策略模式应用：普通货物、加急货物、危险货物三种费率策略
工厂模式配合：通过 RateStrategyFactory 创建对应策略对象
优点分析

将费率计算逻辑封装为独立策略类，便于扩展新货物类型
通过工厂类解耦策略对象创建，提升代码可维护性
Customer 接口实现不同客户折扣，支持后续新增客户类型
职责分离清晰：
Goods 类专注货物计算，Order 类负责订单汇总，Flight 类管理航班状态
各模块功能单一，符合单一职责原则，降低代码耦合度
扩展性设计：
新增客户类型：只需实现 Customer 接口并修改创建逻辑
新增货物类型：实现 RateStrategy 接口并在工厂类注册
新增支付方式：通过 switch 语句扩展，保持代码整洁
计算逻辑优化：
计费重量自动取体积与实际重量的较大值
支持客户折扣计算，总运费 = 基础运费 × 折扣率
结果保留 1 位小数，符合业务精度要求
缺点
1.日期处理优化：
当前问题：使用 String 存储日期，缺乏类型安全与格式校验
2.输入验证增强：
当前问题：缺少对负数重量、空字符串等非法输入的校验
3. 异常处理完善：
当前问题：未处理输入转换异常（如非数字输入）
三.踩坑心得：首先就是非0返回，当货物不符合运送标注，因为没有及时设立边界从而导致非0返回，其次就是格式错误，本人试了很多次才发现自己是输出存在问题而出现错误，本次系统要求多接口同时存在节点可供插入与删除，本人后面才通过List实现此功能。

四.改进建议：
第一次：1. 日期处理优化
采用 Java 8 的LocalDate替代String存储日期，结合DateTimeFormatter进行格式解析与输出，确保日期类型安全与统一（如YYYY-MM-DD格式）。
2. 输入验证增强
对货物尺寸、重量、数量等关键数据添加非负校验；
验证输入字符串（如航班号、地址）非空，避免非法数据导致程序异常；
使用try-catch捕获输入转换异常（如数字格式错误），并给出明确错误提示。
3. Flight 类动态载重管理
添加currentLoad属性记录已装载重量，实现canAccommodate(weight)方法检查剩余载重；
新增addLoad(weight)方法更新当前载重，确保航班容量实时跟踪。
4. Order 类货物动态管理
用List替代固定数组，支持货物添加、删除操作；
实现calculateTotal()方法，在货物列表变更时自动重新计算总重量与总运费。
5. 费率计算策略化设计
引入策略模式：定义RateStrategy接口，不同货物类型（普通、加急、危险品）实现独立费率计算类；
通过工厂类RateStrategyFactory根据货物类型创建对应策略，解耦业务逻辑与核心计算。
6. 客户折扣多态实现
定义Customer接口，声明getDiscountRate()方法；
实现IndividualCustomer（9 折）、CorporateCustomer（8 折）等子类，通过多态支持不同客户折扣策略。
7. 输出格式与代码复用
提取公共输出逻辑到工具类（如PrintUtil），封装订单头部、货物明细等格式化方法；
使用String.format结合占位符（如%-10s）确保表格列对齐，提升输出可读性。
8. 支付方式扩展支持
新增PaymentMethod枚举类定义支付类型（微信、支付宝、现金等），在Order类中实现类型到中文的转换，便于后续扩展。
9. 异常处理完善
在关键业务逻辑（如载重检查、费率计算）中添加异常抛出与捕获，避免程序因数据错误崩溃；
对可能出现的业务异常（如超载）给出明确提示信息。
10. 代码结构优化
拆分过长方法为更小的功能单元，提升代码可读性；
添加必要注释，说明关键业务逻辑（如计费重量计算规则）。
第二次：1. 日期处理优化
采用 Java 8 的LocalDate替代String存储日期，结合DateTimeFormatter统一解析与格式化（如YYYY-MM-DD），确保日期类型安全与格式规范。
2. 输入验证增强
在Goods构造函数中校验尺寸、重量非负，在输入阶段检查货物数量、航班载重等数据有效性，捕获数字格式异常并给出错误提示。
3. Flight 类动态载重管理
保留currentLoad跟踪已装载重量，新增getRemainingCapacity()返回剩余载重，支持多订单容量查询与动态分配。
4. Order 类货物动态管理
将Goods[]改为List，添加addGoods()和removeGoods()方法，实时更新总重量与运费，提升订单灵活性。
5. 费率策略扩展优化
在RateStrategyFactory中通过反射机制与配置文件动态加载策略类，新增货物类型（如易碎品）时无需修改工厂代码。
6. 客户折扣策略扩展
采用工厂模式创建客户对象，通过配置文件映射客户类型（如个人、企业、VIP）与实现类，支持新增客户类型时的解耦扩展。
7. 支付方式枚举化
定义PaymentMethod枚举类，关联支付类型与中文描述（如WECHAT对应 “微信”），提升类型安全性与可维护性。
8. 输出格式优化
使用String.format的固定宽度占位符（如%-15s）格式化表格输出，确保列对齐；封装PrintUtil工具类统一管理输出逻辑，减少代码重复。
9. 业务异常处理增强
在载重检查中返回剩余载重差值，提示用户 “需减少 Xkg”；在订单处理中捕获业务异常并给出详细错误说明（如超载原因）。
10. 输入逻辑模块化
将Main类输入逻辑拆分为CustomerInputHandler、GoodsInputHandler等处理器类，各模块独立负责数据读取与验证，提升代码可读性。
五.总结
第一版是面向对象的基础实现，解决了 “有没有” 的问题，但存在扩展性差、健壮性不足等问题；
第二版通过设计模式优化，提升了系统的可维护性与扩展性，实现了 “好不好” 的进阶，但在日期处理、输入验证等细节上仍有改进空间；
两版演进体现了面向对象设计从 “功能实现” 到 “模式优化” 的过渡，为后续系统迭代奠定了良好基础。