272
社区成员




这是北航面向对象课程最后一个单元的总结,主要是对UML正向建模的理解,当然也有我个人不使用UML的原因。
所谓正向建模,是先使用统一建模语言(UML)设计和创建模型,再将模型转化为可执行的源代码的。
相比JML“设计和实现的分离”,UML也可以认为是一种设计和实现的分离,不需要将方法具体实现,只是确定类、属性和方法,完成程序的骨架,展示类和类之间的关系。
由此观之,实际上我们的迭代任务并非完全意义上的正向建模,只有类图可能践行了这个原则,顺序图、状态图都是后来添加的任务。
本人的确尝试先绘制类图再编写代码,但是很快受挫,主要原因有以下几点:
public void readBook(){}
甚至是比在类图中添加方法更方便的操作。也就是说,在我们的作业中,尽管通过比较复杂的类图评测机制,强制要求实现类图,但在实际执行上是反正向建模的,正向则很有阻力,反过来则海阔天空。
事已至此,状态图是摸鱼完成的这件事已经藏不住了。
不考虑评测机制,认真的说,这个图在电梯单元的报告中我也尝试绘制过,当时认为还是一个比较好的表现方式。个人的观点是,在多线程这种真的要考虑时间的任务上,顺序图的作用比较大,但是在U4的图书管理系统中,这个图并没有帮我们理解太多内容。
如何使用大模型辅助开发,也是吾辈不得不回答的问题。事实上在OO作业中我并没有大量使用大模型辅助,至少不会让代码主体由大模型编写。在实际开发中,我使用ai做了如下工作:
在其他课程的开发任务中,也有使用agent ai,在编写的过程中进行代码补全的。大多数补全错误的情况是由于我的上下文本身编写错误,可见一般来说AI还是比我的能力更强。
必须要心存怀疑,究竟是自己的架构设计能力变强了,还是任务对架构设计的要求下降了。虽然最后的答案往往是两者兼有。
得出结论:任务的难度确有降低,但是能不依靠往年博客自己设计架构也算学有所成。
测试思维的进步,实际上就是摸鱼思维的进步。一开始自己尝试编写评测机,半路崩溃被大佬的评测机搭救,到后来心安理得地求助大佬,一摸到底。说到底,评测机只是为了通过评测不丢分而搭建的,谁搭建的并不重要。
当然写评测机本身也是锻炼代码能力的一个方式。不过并不总是有时间写评测机的,完成其他任务又何尝不能锻炼代码能力呢?所以为了训练而写评测机也只能说是愿者上钩。
不过不测试是不行的,每一行代码都有可能导致bug,怎么平衡花在测试上的时间也是OO课程的一个方面吧。