OOpre课程总结

本文回顾了OOpre课程的作业,涉及架构调整、Solution类的添加、使用Junit进行测试的心得,强调了面向对象编程和代码结构设计的重要性。作者建议课程实践中更注重工程实现并简化文档管理。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

OOpre课程总结

作业最终的架构设计

在这里插入图片描述

其中除了作业要求的冒险者、武器、药水瓶、食物等类外,我自己多实现的类有以下这些:

  1. Solution类:用于处理所有的业务逻辑。由于main类中主函数方法行数的限制,我将各个操作分散到了Solution类中。在主函数中实例化一个solution对象,然后调用该类的read_data()方法,在主函数中只进行输入解析的操作;
  2. Logging类:用于保存战斗日志的信息;
  3. Market类:用于处理最后一次迭代时新增的商店的概念。该类记录了商店的所有日志,同时封装了一些方法以满足作业需求。

在迭代中的架构调整及考虑

和给出的参考代码的作者们相比,我的类比较少,原因是最后两次迭代时我没有按照指导书上写的使用接口,以及工厂模式。因为要是想实现的话,大概率是要把我的代码大改。所以我就不断在原来的代码基础上增加属性/方法,也很惭愧最后终于把代码写成了屎山,感觉要是再迭代几次那肯定得大改了。

唯一一次调整是增加了Solution类,因为一开始把一些简单的业务逻辑放到了主函数里,但是的指令也不多,就侥幸通过了测评。之后想继续这么进行时发现超过行数限制了,所以就增加了一个Solution类将具体处理各条输入指令的代码重构到Solution中了。

在此之后增加的Logging类和Market类都是按着作业要求加的算不上结构上的改变吧。

使用Junit的心得体会

  1. 我觉得Junit的最大作用在于能清晰地看到分支的测试情况。以往写程序时出现的bug大多是因为有一些分支所处理的情况被忽略了,而且自己debug时构造的数据可能也没有把所有分支覆盖到,而Junit测试能让我们清晰地看到这一点,给我在迭代中的debug节省了不少时间;
  2. 合并测试

​ 有时候几个方法甚至几个类都有大面积的重叠,这时候如果对每个类的每个方法都进行了测试,那无疑就是纯粹地为了增加覆盖率而没有任何意义。我们可以在某个测试方法里同时实例化一系列的类的对象,进行他们的组合测试——这样既不会影响覆盖率,而且节省了大量的时间。

学习OOpre的心得体会

这门课可以说让我见识到了除了大一学的结构化编程外的另一种编程思想。最初并不能很好地接受这种改变,甚至很多时候觉得这不是多此一举吗,用C语言结构化地编程能比这样写少不少代码量吧?但随着课程的进行以及迭代作业的推进,我逐渐接受了这一中思想,并且越发觉得这样去编程简直太便利了。

把整个程序看成是由许多对象组成的,每个对象都有自己的属性,以及相应的“行为”——这和真实世界中的感受是何其相似!现在想想迭代的作业,如果不用面向对象的模式去写,那思路可真是太混乱了,可见在解决复杂问题时,面向对象的想法是相当重要的。

同时,我还见识到了代码风格以及代码的结构设计的重要性。代码风格自不必多说,好的码风简直能让人心情愉悦啊。而如何设计架构则是更加重要的,在结课后看同学们的优秀代码,发现原来实现相同的业务逻辑,其实现方法可以天差地别,而同学的优秀代码的架构可读性比我自己写的强很多,而且我也能体会到这样的代码是更易于扩展的。

学习这门课,对我来说是一个全新的挑战,也收获巨大,感谢吴老师以及助教团队的付出!

对课程的简单建议

  1. 老师上课讲的东西过于理论化了,很少落实到代码上去(课件上确实有代码,但是老师课上几乎都是一掠而过),希望老师课上能更注重工程方面的实现。
  2. 最开始发布的课程信息以及各种工具链配置的那个仓库里文件太多太乱了!我觉得一门课程的说明完全不需要分成10多个文件来说明,倒不如直接发布一个PDF文件,里面把课程信息,作业要求,工具链配置使用等等等等都包含在内(多分几个子目录嘛)。要不然一开始对这门课一无所知的同学一看到仓库里10多个文件真的无从下手!
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值