航空货运管理系统

1.前言：

（1）、设计原则考核调整
第一次：主要考核 4 个原则，单一职责、里氏代换、开闭原则、合成复用原则，其中我觉得最主要的还是单一职责原则。
第二次：新增依赖倒转原则，并且新增原则要求代码设计基于抽象层的接口，强化抽象与解耦。
题目如下：
一、计费重量的确定
空运以实际重量（Gross Weight）和体积重量（Volume Weight）中的较
高者作为计费重量。
计算公式：
体积重量（kg） = 货物体积（长×宽×高，单位：厘米）÷ 6000
示例：
若货物实际重量为 80kg，体积为 120cm×80cm×60cm，则：
体积重量 = (120×80×60) ÷ 6000 = 96kg
计费重量取 96kg（因 96kg > 80kg）。
二、基础运费计算2
费率（Rate）：航空公司或货代根据航线、货物类型、市场行情等制定（如
CNY 30/kg）。本次作业费率与货物类型有关，货物类型分为普通货物、危险货
物和加急货物三种，其费率分别为：
计算公式：基础运费 = 计费重量 × 费率 × 折扣率
其中，折扣率是指不同的用户类型针对每个订单的运费可以享受相应的折扣，
在本题中，用户分为个人用户和集团用户，其中个人用户可享受订单运费的 9
折优惠，集团用户可享受订单运费的 8 折优惠。
三、题目说明
本次题目模拟某客户到该航空公司办理一次货运业务的过程：
航空公司提供如下信息：
航班信息（航班号，航班起飞机场，航班降落机场，航班日期，航班最大载
重量）3
客户填写货运订单并进行支付，需要提供如下信息：
 客户信息（姓名，电话号码等）
 货物信息（货物名称，货物包装长、宽、高尺寸，货物重量等）
 运送信息（发件人姓名、电话、地址，收件人姓名、电话、地址，所选
航班号，订单日期）
 支付方式（支付宝支付、微信支付、现金支付）
注：一个货运订单可以运送多件货物，每件货物均需要根据重量及费率单独
计费。
输入格式:
按如下顺序分别输入客户信息、货物信息、航班信息以及订单信息。

客户类型[可输入项：Individual/Corporate]
客户编号
客户姓名
客户电话
客户地址
货物类型[可输入项：Normal/Expedite/Dangerous]
运送货物数量
[货物编号
货物名称
货物宽度
货物长度
货物高度
货物重量
]//[]内的内容输入次数取决于“运送货物数量”，输入不包含“[]”
航班号
航班起飞机场
航班降落机场
航班日期（格式为YYYY-MM-DD）
航班最大载重量
订单编号
订单日期（格式为YYYY-MM-DD）
发件人地址
发件人姓名
发件人电话
收件人地址
收件人姓名
收件人电话
支付方式[可输入项：Wechat/ALiPay/Cash]

2.设计与分析：

（1）第一次航空货运管理系统

类图：

核心类：
Main类：程序入口类，通过main方法启动系统，负责创建Customer、Flight、Order实例，起到系统初始化和流程启动的作用 。
Customer类：封装客户相关信息，如customerId（客户编号）、name（姓名）、phone（电话）、address（地址） 。提供构造方法用于初始化客户对象，在系统中代表使用货运服务的客户实体。
Flight类：管理航班信息，包括flightNumber（航班号）、departureAirport（起飞机场）、arrivalAirport（降落机场）、date（航班日期）、maxLoad（最大载重量）、currentLoad（当前载重） 。canCarry方法用于判断能否承载指定重量货物，addLoad方法用于增加当前载重，体现其对航班载重管理的功能。
Order类：处理订单相关业务，存储orderId（订单编号）、orderDate（订单日期）、senderAddress（寄件地址）等订单信息 。包含goodsList用于管理订单中的货物列表，getTotalChargeableWeight计算订单总计费重量，getPayment计算订单支付金额，负责订单整体业务逻辑处理。
Goods类：描述货物属性，如goodsId（货物编号）、name（名称）、width（宽）、length（长）、height（高）、weight（重量） 。提供getVolumeWeight计算体积重量、getChargeableWeight确定计费重量、getBasicFreight计算基础运费等方法，专注于货物相关数据处理和运费计算。
分析：

创建关系：Main类与Customer、Flight、Order类之间存在创建关系（creates） ，表明Main类在系统启动时负责实例化这些类的对象，构建系统运行基础。
包含关系：Order类与Goods类是包含关系（contains） ，一个订单可包含多个货物，体现订单与货物的业务关联，即订单由货物组成，符合实际货运业务逻辑。

缺点：
1.关系太杂太乱：Order类集订单管理与运费计算于一体，Goods类同时处理属性与重量计算，类功能应单一。
2.扩展受限：新增货物类型（如危险货）或费率规则时，需修改Goods或Order代码，未遵循开闭原则。
3.依赖具体类：Main直接依赖Customer、Flight等具体类，无抽象接口，若替换实现（如航班数据来源变更），需改高层代码，违反依赖倒转（高层应依赖抽象，而非具体实现）。
4.缺少继承适配：未设计货物/用户的基类与子类（如普通/危险货物继承关系），后续若添加子类，较为麻烦。
5. 复用性不足：重量计算（体积、计费重量）逻辑未封装为独立组件，仅在Goods内实现，其他类（如订单汇总计算）无法复用。

总结：这次是为了写题目而写题目，不仅题目的类设计要求未达到，题目的需求也有一定的问题。是一个很失败的代码。不过也算是熟悉代码书写了吧(っ╥╯﹏╰╥c)。

（2）第二次航空货运管理系统

类图：

类图设计分析

• User类：抽象用户基类，子类（IndividualUser、CorporateUser）分别处理个人/集团用户的折扣逻辑，职责清晰。

• Cargo类：抽象货物基类，子类（NormalCargo、ExpediteCargo、DangerousCargo）分别处理不同货物类型的费率计算，专注货物属性与运费规则。

• Payment类：抽象支付基类，子类（Wechat、Alipay、Cash）处理具体支付方式，职责单一。

• Order类：聚合用户、货物、航班、支付信息，负责订单整体计算（如总运费），不掺杂底层细节，职责明确。

• 用户类型：子类（IndividualUser、CorporateUser）继承User，重写getDiscountRate，可在Order中替换User基类，保证折扣逻辑正确。

• 货物类型：子类（Normal、Expedite、Dangerous）继承Cargo，重写getRate，Order中通过Cargo基类调用，子类行为一致。

• 支付方式：子类继承Payment，重写getPaymentMethod，Order依赖Payment基类，子类可无缝替换。

  • 新增货物类型（如“贵重货物”）：只需创建ValuableCargo子类，实现getRate，Order的calculateTotalFreight依赖Cargo基类，无需改动。
  • 新增支付方式（如“银联支付”）：创建UnionPayPayment子类，Order聚合Payment基类，直接扩展。

• 实现方式：通过抽象基类（User、Cargo、Payment）定义稳定接口，变化部分（具体类型）封装为子类，符合“对扩展开放，对修改关闭”。

• Order类：通过聚合（Has-A关系）User、Cargo列表、Flight、Payment，组合各模块功能，而非继承（避免“is-A”的强耦合）。例如：

  • 订单运费计算 = 货物运费（Cargo子类计算） + 用户折扣（User子类计算），通过组合复用各模块逻辑。

总结
这次的就比较完善了，基本践行了五大设计原则：系统也可以灵活扩展（如新增业务规则、技术方案），代码结构也较为清晰，为后续需求迭代（如运费规则调整、用户类型扩展）减轻了负担。
分析：

• 单一职责：类功能内聚，变更影响最小化。
• 里氏代换：子类无缝替换父类，保证行为一致性。
• 开闭原则：新增功能（如货物类型、支付方式）仅需扩展子类，无需修改核心逻辑。
• 合成复用：通过组合复用各模块（如用户折扣、货物费率），避免继承的强耦合。
• 依赖倒转：高层（Order）与底层（子类）均依赖抽象，降低模块间耦合，提升可维护性。

采坑心得
货物类型和用户类型的折扣计算也容易出错。一开始把费率写死在代码里，后来新增货物类型时才发现得用多态，结果子类的getRate()方法名写错了，父类抽象方法没正确实现，编译都过不了。用户折扣也是，一开始在Order类里直接写if判断用户类型，违背了依赖倒转原则，应该通过抽象类的方法获取折扣率，这样扩展新用户类型时才不用改Order的代码。
航班载重检查的边界情况很容易漏。比如当订单总重量刚好等于最大载重时，一开始写的是currentLoad + totalWeight < maxLoad，结果正确的应该是<=，这种边界条件容易错。
浮点精度的问题也很头疼，用double计算运费时，有时候会出现小数点后好多位的情况。
题目没有在算法上面为难我们，需要注意的还是语法问题和类的设计问题，这也是这次题目集设计的本意吧。