302
社区成员




大纲:
先附上一张图,展现各个类及其大致关系(其中commodity为接口)
和其它同学相比,我的类较少,究其原因是往往用一个类做的其它同学多个类的事情。如:在我的Fight
类中,既有fightStart()
方法,控制战斗相关命令,也有fightLog
数组,保存战斗记录。这样做的好处是实现简单,不需要额外写类和方法,缺点点是结构不够清晰,并造成调试方面的困难
增加Fight
类
由于战斗发生在多个冒险者之间,所以Fight
类应当独立于Adventurer
存在。但是由于我前期完成代码时没有对各类的各种属性提供足够多的访问方法,导致在实现过程中对多个类进行了比较大的更改
增加Commodity
接口
问题集中在添加getClassName()
这个方法的过程中。我因为一开始对子类重写父类函数不够熟悉,所以不加思索地写出了几个非常丑的if判断,对后面的开发造成了许多困难
junit的重点是分支测试
在使用junit的过程中,往往会出现弱测和junit都能通过,但在和同学对拍的过程中发现问题的现象。一般来说这种情况都是junit分支测试不全面导致的。
同一个类的测试可以套模板
在测试同一个类的不同方法时(尤其是Bottle
这样的类),往往要先预创建其它实例对象,此时如果给每一个方法都写一个单独的实例化过程会非常耽误时间。可以先写一段比较万能的初始化语句,方便进行测试
不同类的测试有先后顺序
应当按照如上面流程图的拓扑序进行测试,否则在测试子类时会出现”子类是对的,父类错了“的尴尬情况
在编程的世界里,我经历了从面向过程编程(POP)到面向对象编程(OOP)的转变。这一转变让我对编程有了更深的理解,也让我对软件设计有了新的视角。
在POP的世界里,我们关注的是单个过程,如何一步步解决问题。这种思维方式在处理一些简单的问题时非常有效,但对于复杂的问题,POP就显得力不从心。因为复杂的问题往往涉及多个过程,各个过程之间相互影响,难以用单一的过程来理解和解决。
而OOP则为我们提供了一个新的视角。它把世界看作是由许多对象组成的,每个对象都有自己的属性和行为。这些对象通过消息传递相互协作,共同解决问题。这种思维方式更接近现实世界,也更适合解决复杂的问题。
从POP到OOP的转变,对我来说是一个挑战,但也是一个成长的机会。我开始理解到,面向对象编程不仅仅是一种编程技术,更是一种思考问题的方式。它帮助我更好地理解和组织代码,使代码更易于维护和扩展。
同时,OOP也让我理解到,编程不仅仅是写代码,更是设计和规划。在设计和规划的过程中,我们需要考虑代码的结构、模块的划分、对象的交互等问题。这些问题的解决,需要我们对问题有深入的理解,也需要我们有足够的创新思维。