第二次blog作业

前言
本次的两次作业题目集与第一次大作业相比，在难度和复杂度上均有所降低，题量也相应减少。相较于第一次大作业中需要处理复杂的运行逻辑与多层级的设计逻辑，本次题目将侧重点明显转向了类的设计与分类上。具体而言，题目更注重考察代码对设计原则的遵循程度，例如单一职责原则、开闭原则、里氏替换原则等。在类的设计过程中，需要更加精细地划分不同类的职责边界，确保每个类都能专注于完成单一的核心功能；同时，通过合理运用继承、接口、抽象类等面向对象特性，让代码在面对新增需求时能够以 “扩展” 而非 “修改” 的方式应对，充分体现开闭原则的要求。此外，在处理不同类之间的关系时，需严格遵循里氏替换原则，确保子类能够无缝替换父类，避免因继承关系设计不当而导致的代码逻辑漏洞。这种出题导向促使我们跳出 “仅实现功能” 的思维局限，转而从代码结构的合理性、可维护性和可扩展性等更高维度审视编程过程。
第一次作业
本次题目模拟某客户到该航空公司办理一次货运业务的过程：
航空公司提供如下信息：
航班信息（航班号，航班起飞机场所在城市，航班降落机场所在城市，航班
日期，航班最大载重量）
客户填写货运订单并进行支付，需要提供如下信息：
客户信息（姓名，电话号码等）
货物信息（货物名称，货物包装长、宽、高尺寸，货物重量等）
运送信息（发件人姓名、电话、地址，收件人姓名、电话、地址，所选
航班号，订单日期）
支付方式（支付宝支付、微信支付）
注：一个货运订单可以运送多件货物，每件货物均需要根据重量及费率单独
计费。
程序需要从键盘依次输入填写订单需要提供的信息，然后分别生成订单信
息报表及货物明细报表。
第一次作业的类图：

方法分析:

代码分析：

行数：294 行。
语句数：192 条。
分支语句占比：4.7% 。
方法调用语句数：24 。
含注释行占比：3.7% 。
类和接口数量：7 个。
每个类的平均方法数：12.57 。
每个方法的平均语句数：2.06。
最复杂方法的行号：140 。
最大复杂度：7 。
最深代码块行号：133 ，最大代码块深度：3。
平均代码块深度：1.54 ，平均复杂度：1.38。
改进建议：
根据代码度量数据，可从以下方面改进代码：一是优化代码结构与复杂度，针对最大复杂度为 7 的方法（行号 140），可通过拆分复杂方法、使用策略模式等降低复杂度，同时对最大深度 3 的代码块采用提前返回、提取布尔变量等方式减少嵌套层级；二是提升代码可读性与可维护性，鉴于含注释行占比仅 3.7%，需为类、方法及关键逻辑添加注释，并规范类名命名（如Factorycustomer改为CustomerFactory、Zhifubaopay改为Alipay），统一格式以增强可读性。
踩坑心得：
本次编写代码的初始阶段，逻辑上确实存在些许混乱，对具体类之间的关联和联系认知模糊。由于最开始缺乏对整体的设计和分析，一度陷入不知从何处下手的困境，面对题目要求时大脑一片空白，完全找不到清晰的思路。但后来意识到，一味地空想不如付诸行动，于是尝试从最基础的部分开始敲写代码，抱着 “先完成局部，再拼凑整体” 的心态，一点一点着手准备。在逐步编写的过程中，代码的雏形和结构竟随着键盘的敲击声慢慢显现出来。每完成一个类的定义、每实现一个方法的逻辑，都像是在为一幅拼图找到合适的板块，自己的逻辑思维也在这个过程中愈发清晰，对题目的理解也从最初的模糊变得深刻透彻。当各个类之间的关联通过代码逐步建立起来时，整个问题的脉络逐渐清晰可见，到后面竟有种 “水到渠成” 的顺畅感，不知不觉中就完成了题目的要求的功能需求。这段经历让我深刻体会到，面对编程难题时，最关键的是不要害怕困难和繁琐，主动去理解题意、尝试动手实践，在试错中积累经验、梳理思路。就像这次遇到的错误，出在输出格式上 —— 正确格式中包含箭头符号，而我最开始并未意识到是箭头的问题，误以为是逻辑错误，在代码逻辑层面反复调试了许久却始终不得其解。直到仔细对照题目要求，才发现是输出符号的细节偏差。总的来说，这次代码编写经历让我在磕磕绊绊中收获了宝贵的经验：面对复杂问题时，先行动起来，在实践中构建思路；同时，注重细节，养成严谨的编码习惯，如此才能一步步突破困境，最终实现目标。
第二次作业
本次题目模拟某客户到该航空公司办理一次货运业务的过程：
航空公司提供如下信息：
航班信息（航班号，航班起飞机场，航班降落机场，航班日期，航班最大载重量）
客户填写货运订单并进行支付，需要提供如下信息：
客户信息（姓名，电话号码等）
货物信息（货物名称，货物包装长、宽、高尺寸，货物重量等）
运送信息（发件人姓名、电话、地址，收件人姓名、电话、地址，所选航班号，订单日期）
支付方式（支付宝支付、微信支付、现金支付）
注：一个货运订单可以运送多件货物，每件货物均需要根据重量及费率单独计费。
这次的题目要求在第一次的基础上，本次作业费率与货物类型有关，货物类型分为普通货物、危险货物和加急货物三种，基础运费 = 计费重量 × 费率 × 折扣率其中，折扣率是指不同的用户类型针对每个订单的运费可以享受相应的折扣，在本题中，用户分为个人用户和集团用户，其中个人用户可享受订单运费的 9折优惠，集团用户可享受订单运费的 8 折优惠。支付方式也扩展为三种支付方式 支付宝支付、微信支付、现金支付。
第二次作业的类图：

方法分析:

代码分析：

行数：共 478 行。
语句数：有 202 条。
分支语句占比：为 9.4% 。
方法调用语句数：是 24 条。
带注释行占比：仅 4.4% 。
类和接口总数：有 8 个 。。
平均每类方法数：达 10.50 个。
平均每方法语句数：1.99 条，体现方法平均规模。
最复杂方法行号：在 194 行，是 DangerousGood.getFreight() 方法。
最大复杂度：为 5 。
最深代码块行号：位于 197 行，最大代码块深度为 3 ，平均代码块深度是 1.21 ，衡量代码块嵌套深度。
平均复杂度：为 1.18 。
改进建议：
带注释行占比：仅 4.4% ，需补充类注释、方法注释和关键逻辑注释；对于支付方式相关类，也可以进一步提取更通用的接口，比如定义一个获取支付相关信息（如支付金额、支付状态等）的接口，让 Wechatpay 、Zhifubaopay 、Xianjinpay 等类实现，以规范支付方式的行为；Orderdetail 类依赖多个类（OrderInfo、Flight、List、Customer、Paymentway ），可以考虑使用依赖注入的方式来降低耦合度，使类的职责更加单一，比如通过构造函数注入这些依赖对象，并且在需要时可以方便地替换不同的实现。
踩坑心得：
本次作业的核心任务是对首次编写的代码进行重构与扩展，需要新增人员身份类型、物品种类以及支付方式等功能模块。较于第一次从零开始搭建代码框架，这次任务虽在形式上是 “添砖加瓦”，但实际操作中却需要对原有代码结构进行深度剖析与调整。扩展过程中，最具挑战性的部分在于妥善处理不同类之间错综复杂的关系 —— 既要确保新增类与原有类的兼容性，又要避免因类间耦合度过高而导致代码逻辑混乱。在新增人员身份时，需要精准定位原有客户类的继承体系，判断是通过抽象类扩展还是新增接口来实现新身份的功能差异化；在处理物品种类时，则要细致考量不同物品的计费规则、运输限制等特性，通过多态机制在同一方法下实现差异化处理。得益于第一次代码编写的经验铺垫，第二次任务更多聚焦于 “增量式完善”—— 在原有类结构的基础上，有针对性地添加扩展点，根据不同业务场景细化处理逻辑。本次花费时间较多的点还是后续的为了满足设计原则，一直在不断的修改修改和完善，过程中的功能实现部分有了第一次做铺垫还是相对比较轻松的。
总结：
这次的大作业，题量相较于以往确实有所减少，难度也大幅降低。起初看到作业要求时，心里还暗自松了口气，想着或许能轻松应对。然而，在实际动手编写代码的过程中，我才发现其中蕴含着诸多值得深入探究的细节。
随着代码一行行地在编辑器中呈现，我愈发清晰地感受到，即便题量和难度有所下降，它所带来的收获却丝毫不减。在反复琢磨代码结构、不断优化逻辑的过程中，我深刻体会到了一个精妙设计对于提升代码质量的关键意义。就拿类的设计来说，合理的类结构与清晰的职责划分，能够让代码在运行时更加稳定高效，在维护时也更加轻松便捷。这使我明白，代码绝非仅仅实现功能就万事大吉。一个真正优秀的代码作品，不仅要功能完备，更要在代码质量上达到高水准。从代码的可读性、可维护性，到可扩展性，每一个维度都至关重要。

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！