242
社区成员




面向老师ppt的设计 (๑•̀ㅂ•́)و✧
Main:调输入接口+调Manager处理输入
MyScanner:输入处理
Manager:指令分类
Adventurer:指令执行
Log:存有战斗日志的信息,进行战斗日志内容解析逻辑
Shop:单例模式
Commodity:Adventure、Bottle、Equipment、Food类实现
不同Bottle、Equipment:继承实现
在hw1-hw4,我一直通过if-else
把指令执行与分类强行挤在Main类里,踩着60行的红线进行缩句┐=͟͟͞͞( ̄ー ̄)┌
if(op == 1){
//operation1
}else if(op == 2){
//operation2
}……
hw5之前老师在课上推荐层次化架构,“各司其职”。于是我破釜沉舟将Main类拆分出为MyScanner类和Manager类
这极大便利了后续的迭代(最后23条指令 23*2 = 46 Main真的吃不消)
最后一次本来想把Bottle、Equipment、Food类再提取一个父类来着,结果个人能力和精力有限┐=͟͟͞͞( ̄ー ̄)┌
我开始接触学习单元测试,如何构造特殊样例,考虑极端值情况,将题目中可能出现的所有情况不重不漏的呈现。磨覆盖率的过程是痛苦却有趣的(会在写战斗日志的时候幻想冒险者的爱恨情仇 ),且是极有宜于debug的,好多次在写junit时发现自己理解错了题意˶´⚰︎`˵
因为重构代码将manager类与main类剥离,所以走上了在manager类里写整体测试数据,不对每一部分测试来快速刷满覆盖率的不归路。我为此付出了沉重的代价,终于意识到单元测试的意义和自行构造样例的必要。
很难想象如果不是最后一次强侧让我回头是岸,oo正课开始我将如何度过……
失败卒获有所闻,这就是《失败的艺术》吧。
因为一开始上手的是C语言,所以思考问题时不自觉会在脑子里画个流程图,照着图“翻译”代码。
但这门课要求我必须要将这个过程抽象成一些具有相同特征和行为的“对象”的相互作用。在痛苦的思维转变中,我逐渐体会了面向对象的妙处。
可以做一个不恰当的比喻:CO的logisim直接连线 vs 模块化层次化善用tunnel?
提炼多个类重复部分形成父类,大道至简的优雅,可惜我没把bottle、equipment、food这三个再提取个父类。
接口服务于多个类之间共性的行为,提高了我的代码的灵活性、可拓展性。
一开始只觉得即使可以ctrl+alt+L
,checkstyle也很繁琐,一个方法不能超过60行、一个类不能超过500行更是为难人,只能按照函数的步骤功能进行艰难拆分 o(~ヘ~o#)
后来实践中才明白一个函数越长、一个类功能越多,越难以理解和维护。良好的代码风格才有较高可读性。
希望多涉及一些关于git的使用知识(。•̀ᴗ-)✧
犹忆hw2犯蠢在gitlab上删了代码之后,本地一直push不上去,自己对着Git pro和网上的教程越改越糟,还好有好心的同学浇浇 我太愚蠢了
开始小作文:)检查作业的助教老师可以走力
其实一直没有勇气写这篇总结
最后一次打开强测页面时的满页飘红,现在时不时想起来还会很难受(つ﹏⊂)
但是迫于ddl的压力 还是要为oopre课程画下一个圆满(?)的句号,毕竟总结错误的经验教训才是《失败的艺术》
很感谢oopre课程组的老师们和助教老师们,微信群里不间断的答疑,让我知道这门课程要求不停迭代的目的是,大家一起努力提升优化,而不是要为难同学们,所以强测被hack的时候也没那么难过了wwww
下一次正课再见时,一定不会这么狼狈了,我们来日方长!!!( ´͈ ᵕ `͈ )◞♡