题目集8~9的总结
前言
（总结两次题目集的知识点、题量、难度等情况）
第八次题目集
本次题目集的题目分别为：
点线面问题重构（继承与多态）、雨刷程序功能扩展设计、航空货运管理系统（类设计）
1. 知识点
主要知识点有(1).继承与多态(2).类设计（3).抽象类与接口
2.题量
题量适中
3.难度
难度中等
第九次题目集
本次题目集的题目分别为：
魔方问题、点线面问题再重构（容器类）、航空货运管理系统（继承与多态）
1. 知识点
主要知识点有(1).容器类(2).继承与多态
2.题量
题量适中
3.难度
难度较难
设计与分析
(重点对题目的提交源码进行分析)
第八次题目集
题目：点线面问题重构（继承与多态）
SourceMonitor报表分析
度量指标
方法数量：每个类有合理数量的方法(3-6个)
继承深度：合理的单层继承结构
耦合度：Line类与Point类有合理耦合
方法复杂度：所有方法都很简单，复杂度低
注释率：代码缺乏注释，需要改进
关键指标
抽象类使用：正确使用了抽象类和抽象方法
多态应用：Main类中展示了良好的多态应用
封装性：所有属性都是private，通过getter/setter访问
类图分析
Element抽象类
作为所有图形元素的基类
定义了抽象的display()方法，强制子类实现
体现了"依赖倒置"原则，高层模块依赖于抽象
Point类
表示二维坐标系中的点
良好的封装：私有属性+公共访问方法
display()方法格式化输出坐标，保留两位小数
Line类
表示带颜色的线段
包含两个Point对象，演示了对象组合
getDistance()方法计算线段长度（两点间距离）
display()方法显示完整线段信息
Plane类
最简单的图形元素，只有颜色属性
演示了继承体系的扩展性
心得总结
这段代码很好地演示了面向对象编程的几个核心概念：
继承：通过Element抽象类建立继承体系
多态：Main类中统一处理不同类型的Element
封装：所有类都隐藏内部实现细节
抽象：Element类定义了高层抽象概念
在实际项目中，这种设计模式非常有用，特别是当系统需要处理多种类似但又有差异的对象时。通过抽象基类定义共同接口，可以大大简化客户端代码，提高系统的扩展性和维护性。
题目：雨刷程序功能扩展设计
SourceMonitor报表分析
度量指标
方法数量：每个类有合理数量的方法(3-8个)
继承深度：合理的单层继承结构
耦合度：Agent类与其他类耦合度较高，但这是设计需要
方法复杂度：calculateSpeed()方法复杂度较高，但可接受
注释率：代码缺乏注释，需要改进
关键设计指标
抽象工厂模式：通过WiperSystemFactory创建相关对象族
策略模式：SpeedStrategy封装了速度计算算法
多态应用：通过工厂创建不同类型的组件
封装性：所有属性都是private，通过方法访问
类图分析
工厂接口和实现
interface WiperSystemFactory {
Lever createLever();
Dial createDial();
SpeedStrategy createSpeedStrategy();
}
class BasicWiperSystemFactory implements WiperSystemFactory {
// 创建基本型组件
}
class AdvancedWiperSystemFactory implements WiperSystemFactory {
// 创建高级型组件
}
抽象工厂模式让系统可以创建一组相关对象
方便扩展新的雨刷系统类型
策略模式实现
interface SpeedStrategy {
int calculateSpeed(int leverPos, int dialPos);
}
class BasicSpeedStrategy implements SpeedStrategy {
// 基本型速度计算逻辑
}
class AdvancedSpeedStrategy implements SpeedStrategy {
// 高级型速度计算逻辑
}
将速度计算算法封装成独立策略
可以独立变化而不影响其他组件
控制组件实现
abstract class Lever {
// 公共控制杆逻辑
public abstract String getPositionName();
}
class BasicLever extends Lever {
// 基本型控制杆实现
}
class AdvancedLever extends Lever {
// 高级型控制杆实现
}
模板方法模式：抽象类定义骨架，子类实现细节
控制杆位置名称由具体子类决定
Agent协调类
java
class Agent {
private Lever lever;
private Dial dial;
private Brush brush;
private SpeedStrategy speedStrategy;
public void processOperation(int choice) {
// 处理用户操作
updateBrushSpeed();
}
}
作为系统的协调者，封装了核心业务逻辑
负责接收操作并更新系统状态
心得总结
这段代码展示了几个重要的设计模式在实际问题中的应用：
抽象工厂模式：优雅地创建相关对象族，支持多种雨刷系统配置
策略模式：封装变化点，使速度计算算法可以独立变化
模板方法模式：在Lever类中定义操作骨架，子类实现细节
这种设计的主要优势在于：
系统结构清晰，各组件职责明确
扩展新类型雨刷系统非常方便
算法变化不会影响其他组件
客户端代码(Agent)与具体实现解耦
在实际的汽车电子系统开发中，这种设计模式非常适用，因为它：
支持不同车型的配置变化
便于维护和升级
组件可测试性强
适应需求变化的灵活性高
题目：航空货运管理系统（类设计）
（重点分析）
SourceMonitor报表分析
度量指标
方法数量：各类方法数量适中(3-10个)
继承深度：合理的单层继承结构
耦合度：Agent类与其他类耦合度较高
方法复杂度：huowuxingxi中的计费计算方法复杂度较高
注释率：代码完全缺乏注释，严重影响可读性
关键指标
继承结构：合理使用抽象基类xingxi
组合关系：yunsongxingxi包含huowuxingxi列表
接口应用：支付方式使用接口定义
业务逻辑：运费计算和载重检查逻辑完整
类图分析
核心类分析
xingxi抽象类
abstract class xingxi {
private String bianhao;
// ...getter/setter...
abstract void display();
}
作为所有信息类的基类
定义了编号属性和显示抽象方法
体现了模板方法模式
huowuxingxi类
class huowuxingxi extends xingxi {
// 多种货物属性
double tijizhongliang = changdukuandugaodu/6000; // 体积重量计算
// 复杂的运费计算方法...
}
包含完整的货物信息和运费计算逻辑
计算体积重量和实际重量的较大值作为计费重量
根据重量区间计算费率
yunsongxingxi类
class yunsongxingxi extends xingxi {
private ArrayList
// 管理货物列表和计算总运费
}
核心业务类，管理订单信息
包含发件人和收件人信息
计算订单总重量和总金额
支付系统
interface zhifufangshi {
void zhifujiner();
}
class weixinzhifu implements zhifufangshi {
// 微信支付实现
}
简单但可扩展的支付接口设计
目前只实现了微信支付
Agent协调类
class Agent {
// 组合客户、航班和运输信息
Boolean shifoukeyizhuangxia() {
return hangbanxingxi2.getzaizhongliang() >= yunsongxingxi2.getzongzongliang();
}
// 显示完整订单信息
}
系统的协调中心
检查航班载重能力
显示完整订单信息
心得总结
这段代码展示了一个完整的航空货运业务系统，具有以下特点：
业务逻辑复杂但完整：
体积重量与实际重量比较
分段费率计算
航班载重检查
面向对象特性应用：
继承用于信息类统一管理
组合用于订单与货物关系
接口用于支付系统扩展
实际应用价值：
系统设计符合实际货运业务需求
核心计算逻辑具有商业实用性
数据结构设计合理
主要问题在于代码可读性和可维护性：
拼音命名严重影响代码理解
缺乏注释增加维护难度
部分类职责过重(如huowuxingxi)
改进方向：
首先解决命名问题，使用英文专业术语
添加全面注释，特别是业务逻辑部分
重构复杂类，分解职责
增强系统健壮性，添加异常处理
第九次题目集
题目：魔方问题
SourceMonitor报表分析
度量指标
方法数量：每个类有3-5个方法，数量适中
继承深度：合理的两层继承结构
耦合度：RubikCube与Solid耦合合理
方法复杂度：所有方法都很简单，复杂度低
注释率：代码完全缺乏注释
关键指标
抽象类使用：正确使用了抽象类和抽象方法
多态应用：Main类中通过抽象类引用调用具体实现
封装性：所有属性都是private/protected，通过方法访问
类图分析
核心类分析
Solid抽象类
abstract class Solid {
protected double side;
abstract double getSide();
abstract void setSide(double side);
abstract double getArea();
abstract double getVolume();
}
作为所有几何体的基类
定义了边长属性和基本操作方法
使用protected修饰side，允许子类直接访问
具体几何体类
class Cube extends Solid {
// 实现立方体的面积和体积计算
}
class RegularPyramid extends Solid {
// 实现正四面体的面积和体积计算
}
各自实现了几何计算的具体逻辑
公式正确：立方体V=a³，正四面体V=a³√2/12
RubikCube抽象类
abstract class RubikCube {
private String color;
private int layer;
private Solid solid;
// 抽象方法
abstract double getArea();
abstract double getVolume();
}
表示多层魔方的抽象概念
包含颜色、层数和基本几何体
定义了计算面积和体积的抽象方法
具体魔方类
class SquareCube extends RubikCube {
// 实现立方体魔方的计算
}
class RegularPyramidCube extends RubikCube {
// 实现四面体魔方的计算
}
计算考虑了层数的影响：面积与层数平方成正比，体积与层数立方成正比
公式正确反映了魔方的几何特性
Main类分析
public class Main {
public static void main(String[] args) {
// 输入处理
RubikCube cube1 = new SquareCube(...);
RubikCube cube2 = new RegularPyramidCube(...);
display(cube1);
display(cube2);
}
static void display(RubikCube cube) {
// 统一显示魔方信息
}
}
良好的多态应用：通过RubikCube抽象类处理不同具体魔方
显示方法格式化输出，保留两位小数
心得总结
这段代码展示了面向对象设计在几何计算中的应用，主要特点包括：
良好的抽象：通过Solid和RubikCube抽象类定义共同接口
多态威力：Main类无需关心具体魔方类型
数学正确性：几何计算公式准确
扩展性强：可以轻松添加新的几何体和魔方类型
主要改进空间：
工程实践方面：注释、命名、输入验证等
数学常量可以缓存以提高性能
可以考虑使用设计模式进一步解耦
这种类型的系统在CAD建模、游戏开发等领域有实际应用价值。良好的设计可以使系统更容易维护和扩展，特别是当需要支持更多几何类型时。
核心设计思想值得借鉴：
将不变的部分（几何计算）与可变的部分（魔方特性）分离
通过抽象层降低耦合度
利用多态简化客户端代码
题目：点线面问题再重构（容器类）
SourceMonitor报表分析
度量指标
方法数量：每个类有3-8个方法，数量适中
继承深度：合理的单层继承结构
耦合度：GeometryObject与Element耦合合理
方法复杂度：Main类的while循环复杂度较高
注释率：代码完全缺乏注释
关键指标
抽象类使用：正确使用Element抽象类
多态应用：通过Element抽象类处理不同几何对象
封装性：所有属性都是private，通过方法访问
类图分析
核心类分析
Element抽象类
abstract class Element {
abstract void display();
}
作为所有几何元素的基类
定义了display()抽象方法，强制子类实现
简单但有效的抽象设计
具体几何元素类
class Point extends Element {
// 点坐标和显示实现
}
class Line extends Element {
// 线段(两点+颜色)和显示实现
// 包含计算线段长度的方法
}
class Plane extends Element {
// 平面(颜色)和显示实现
}
各自实现了特定的几何元素
Line类包含业务逻辑(计算长度)
显示格式统一保留两位小数
GeometryObject管理类
class GeometryObject {
private ArrayList
// 添加、删除和获取元素列表的方法
}
核心管理类，维护几何对象集合
提供简单的CRUD操作
索引处理需要注意(remove(index-1))
Main类分析
public class Main {
public static void main(String[] args) {
// 菜单式交互处理
while(choice != 0) {
switch(choice) {
// 处理各种操作
}
}
// 显示所有几何对象
for(Element e:geome.getList()) {
e.display();
}
}
}
采用简单的控制台菜单交互
输入验证确保坐标在(0,200]范围内
利用多态统一处理各种几何对象
缺乏错误恢复机制(直接System.exit)
心得总结
这段代码展示了面向对象设计在几何图形管理中的应用，主要特点包括：
良好的抽象：通过Element抽象类统一几何对象接口
多态威力：统一管理不同类型的几何对象
封装性：隐藏实现细节，暴露必要接口
实用功能：包含基本的几何计算(线段长度)
主要改进空间：
工程实践方面：注释、错误处理、交互设计
功能完整性：缺乏编辑和持久化功能
健壮性：输入处理可以更完善
这种类型的系统在CAD软件、图形编辑工具中有实际应用价值。当前设计具有良好的扩展性，可以方便地添加新的几何类型(如圆形、多边形等)。
值得借鉴的设计思想：
抽象基类定义共同接口
集合管理配合多态处理
业务逻辑与显示分离
题目：航空货运管理系统（继承与多态）
(重点分析)
SourceMonitor报表分析
度量指标
方法数量：核心类有5-10个方法，数量适中
继承深度：合理的两层继承结构
耦合度：Agent类与其他类耦合度较高(设计需要)
方法复杂度：运费计算方法复杂度中等
注释率：代码完全缺乏注释
关键指标
抽象类使用：正确使用抽象类定义核心接口
多态应用：通过抽象类处理不同客户/货物类型
封装性：属性私有，通过方法访问
单一职责：各类职责划分明确
类图分析
核心类分析
客户体系(kehu)
abstract class kehu {
// 客户基本信息
abstract double getzhekoulv();
}
支持个人客户(9折)和企业客户(8折)
折扣率作为抽象方法由子类实现
货物体系(huowu)
abstract class huowu {
// 计算体积重量和实际重量的较大值
double getjifeizhongliang() {
return max(体积重量, 实际重量);
}
abstract double getfeilv(); // 费率计算
abstract double getyunfei(); // 运费计算
}
支持普通、加急和危险品三种货物
每种货物有不同费率标准
计算逻辑考虑了体积重量和实际重量
航班管理(hangban)
class hangban {
// 航班基本信息+最大载重限制
}
记录航班起降信息和载重限制
用于检查货物总重量是否超限
订单管理(dingdan)
class dingdan {
// 订单基本信息+收发件人信息
}
记录订单核心信息
关联发货人和收货人数据
支付系统(zhifu)
abstract class zhifu {
abstract String gettype();
}
支持微信、支付宝和现金支付
简单但可扩展的设计
货物容器(huowurongqi)
class huowurongqi {
private ArrayList
// 管理货物列表并计算总重量和总运费
}
核心业务类，管理订单中的货物集合
提供总重量和总运费计算
协调者(Agent)
class Agent {
// 协调各组件工作
void display() {
// 显示完整订单信息
// 检查载重限制
}
}
系统的核心协调者
负责业务流程控制和信息展示
包含业务规则验证(载重检查)
心得总结
这段代码展示了一个完整的业务系统设计，主要特点包括：
完善的业务建模：
准确反映了航空货运的业务规则
体积重量与实际重量比较
分段费率计算
客户折扣体系
良好的OO设计：
抽象类定义核心接口
多态处理业务变化
合理的类职责划分
实际应用价值：
系统设计符合行业实际需求
核心计算逻辑具有商业价值
数据结构设计合理
主要改进空间：
工程实践：命名、注释、异常处理
用户体验：交互提示和错误恢复
性能考虑：大量货物时的计算效率
这种类型的系统在物流行业有广泛应用，良好的设计可以：
降低维护成本
提高扩展灵活性
保证业务规则一致性
提升代码可读性和可测试性
采坑心得
(对源码的提交过程中出现的问题及心得进行总结)
提交过程中遇到的典型问题
1.命名规范问题
-
大量使用拼音命名（如kehu、huowu等），降低了代码可读性
-
解决方案：改用英文专业术语（如Customer、Cargo），采用驼峰命名法
2.代码注释缺失
-
整个代码库几乎没有注释
-
解决方案：添加完整的Javadoc注释，关键算法添加行内注释
3.异常处理不足
-
多处直接使用System.exit(0)，缺乏友好的错误恢复机制
-
解决方案：引入自定义异常类，实现优雅的错误处理流程
4.设计模式应用不充分
-
虽然使用了继承，但工厂模式、策略模式等应用不够
-
解决方案：将费率计算等业务逻辑提取为策略模式
5.输入验证缺失
-
对用户输入缺乏全面验证
-
解决方案：添加边界检查、格式验证等
技术层面的心得体会
1.面向对象设计
-
抽象类和多态的使用是亮点，但可以进一步优化：
-
将变化点（如折扣率、费率）提取为接口
-
考虑使用组合替代继承的部分场景
2.业务逻辑封装
-
运费计算等核心业务逻辑封装良好
-
建议：将业务规则（如重量分段）配置化，提高灵活性
3.模块化设计
-
各组件职责划分基本清晰
-
改进点：可以按功能模块分包（如customer、cargo、payment等）
工程实践方面的收获
1.版本控制经验
-
频繁的小步提交比大改动后一次性提交更安全
-
有意义的commit message非常重要
2.代码审查意识
-
通过审查发现了很多命名和设计问题
-
建立代码规范文档非常必要
3.测试驱动开发
-
缺乏单元测试导致修改时缺乏信心
-
体会：应该先写测试再开发功能
项目管理方面的启示
1.需求分析
-
前期需求理解不深导致部分设计不合理
-
教训：应该先完善需求文档再编码
2.进度把控
-
功能开发时间预估不准确
-
改进：拆解任务，使用敏捷开发方法
3.文档建设
-
系统缺乏设计文档和使用说明
-
经验：文档应与代码同步更新
改进建议
(对相应题目的编码改进给出自己的见解，做到可持续改进)
- 架构优化
-
引入分层架构（表现层、业务层、持久层）
-
考虑微服务化改造
2.性能优化
-
大数据量下的计算性能需要关注
-
引入缓存机制
3.安全加固
-
添加敏感数据加密
-
完善权限控制
4.DevOps实践
-
建立CI/CD流水线
-
引入代码质量扫描工具
总结
(对本阶段两次题目集的综合性总结)
通过本次项目开发，深刻体会到：
1.良好的编码习惯比实现功能更重要
2.设计阶段多花时间能大幅减少后期修改成本
3.文档和测试不是可选项，而是必选项
4.代码评审是提高质量的有效手段
5.保持持续重构的意识至关重要
浙公网安备 33010602011771号