You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
20 lines
2.9 KiB
20 lines
2.9 KiB
本次图形面积计算器重构实验，让我对面向对象的核心思想有了更直观的理解，也发现了自身在设计与实践中的不足，现将反思总结如下：
|
|
1.抽象思维的重要性：最初我只是想分别写三个图形的计算方法，直到设计抽象类Shape时才意识到，抽象是统一接口的关键。通过抽象方法约束子类行为，才能真正实现 “统一处理不同图形” 的目标，这让我明白抽象不是 “空泛”，而是为了更好的复用与扩展。
|
|
2。多态的实际价值：之前对多态的理解停留在概念层面，这次通过ShapeUtil的printArea方法，我真切体会到多态的便利 —— 不需要判断图形类型，只要传入Shape子类对象就能自动调用对应计算逻辑，代码变得简洁且易于维护，新增图形时几乎不用修改原有代码。
|
|
3.规范意识的欠缺：在单文件多类、抽象方法语法、@Override注解等细节上，我多次因为不熟悉规范而踩坑，比如类重复编译错误、多态调用失效等。这提醒我，严谨的语法规范是代码可运行的基础，今后要更重视基础语法的学习与实践。
|
|
4.文档与可视化的价值：绘制类图时，我才清晰看到类之间的继承与依赖关系，这比单纯看代码更直观。这让我认识到，类图等可视化工具是梳理设计思路、沟通交流的重要手段，今后要养成先画设计图再写代码的习惯。
|
|
|
|
|
|
组合vs继承
|
|
（1）本次实验中使用继承的原因
|
|
代码复用：三个图形都有getArea()方法，通过继承抽象类Shape，避免重复编写抽象方法声明
|
|
统一接口：继承让所有图形拥有统一的getArea()方法，使得ShapeUtil可以通过多态统一处理所有图形，无需为每个图形单独写打印方法
|
|
（2）组合 vs 继承的核心区别
|
|
|
|
维度 继承 (Inheritance) 组合 (Composition)
|
|
关系 “is-a” 关系（如：Circle is a Shape） “has-a” 关系（如：ShapeUtil has a Shape）
|
|
耦合度 高耦合，子类依赖父类的实现 低耦合，通过接口交互，依赖度低
|
|
适用场景 类之间存在明确的层级关系，且需要复用代码 类之间是整体与部分的关系，需要动态组合功能
|
|
缺点 父类修改可能影响子类，打破封装 代码相对繁琐，需手动组合对象
|
|
|
|
（3）如果后续需要新增更多图形（如正方形、梯形），继承依然适用，因为正方形、梯形都属于 “图形” 的子类，符合 “is-a” 关系。但如果需要给图形新增非核心功能（如：绘制图形的颜色、获取图形的边框），可考虑用组合（如创建ColorUtil工具类组合进Shape），避免继承导致的类臃肿。
|