架构设计
在执行指令时,各个部分的整体访问逻辑如下
-
Main
-
Adventurer
-
Bottle
-
RegularBottle
-
ReinforcedBottle
-
RecoverBottle
-
-
Equipment
-
RegularEquipment
-
EpicEquipment
-
CriticEquipment
-
-
Food
-
FightLog
-
Commodity
-
Adventurer
-
Bottle
-
Equipment
-
Food
-
-
-
Store
-
Bottle
-
Equipment
-
Food
-
-
FightLog
-
ps: 除去Commodity是Interface外其他都是Class,但为了清晰表现架构都放入一个列表中
本人编写的程序在运行过程中:
- 同级的类不会互相访问
- 上级向下级访问时不会越级访问(如Adventurer访问RegularBottle)
- 不会发生下级访问上级的情况
本人对整体架构的评价
缺点
- Main函数臃肿,接近300行,应添加Interface来简化
- Store的内容比较混乱,应以抽象或简单工厂模式实现
- 多个Class都可以访问Bottle、Equipment、Food,未想到如何改进
优点
- FightLog的实现非常优雅,与其他类的关系非常清晰
- Main在处理指令时整体较为简洁
在迭代中的架构调整
- 前三次次迭代中Main类可以访问所有其他类,在第四次迭代中建立了管理关系,进行了封装
- 尝试对Main类中的方法进行封装放入Method中,由于出现了多处bug遂放弃
使用Junit的心得体会
优势
- Junit可以在未完成一次迭代时对方法进行单元测试,确认其功能正确
- 查看断言结果即可判断方法正确性,因此可以在不修改源文件的情况下测试代码
- 构造数据相对简单,且一次运行可以完成多次测试
问题
- 无法检查出整体代码的逻辑问题(测试Main时找不到的问题,Junit也找不到)
- 不方便测试的方法最后还是需要用Main才能测试,如涉及到输入输出、参数不易直接构造
面向对象编程的心得体会
第一次接触到面向对象编程,对这样的编程方式非常认同。相比于大一学习C语言程序设计时的面向过程编程,面向对象编程似乎更适合代码量大的程序开发(app、游戏等)。加之面向对象编程更贴近人类的思维模式,在设计程序的时候非常自然,产生的bug也更好理解(虽然不好找)。它强调的封装、继承与多态极大的降低了代码阅读者的理解难度与代码编写者的修改难度,增加了简洁度,个人认为也是一种极佳的编程习惯。
对于课程的建议
- 增加Junit使用的详细教程,取消对于Junit覆盖率的硬性要求,毕竟用什么方式debug因人而异
- 建议在初学时增加一些有面向对象特点的内容,让学生更早认识到其与面向过程编程的区别,防止在迭代中出现多次大规模的架构调整
2023.11.4