面向对象设计与构造2022 (北京航空航天大学 - 计算机学院)

很棒的一篇博客，非常详细非常用心！！！也感谢同学对OO课程的肯定以及提出的意见！

UML架构图当然要方法属性啦！变量名太长其实也不方便代码阅读，建议还是养成好习惯在变量名里用点缩写形式吧！总的来讲同学在OO学习里还是有很大收获的，希望同学能够将面向对象的思维用在未来更多的工程项目中。

架构设计的总体思路不错（康来课程组的CheckStyle还是相当有用的），但是分析不够深入（最好应该摆出UML图讲讲各类之间的协同关系）。可以看出同学通过OO课程的学习已经有了较好的面向对象思想，那希望你能够学以致用，把这种思想用在后续的编译实验及未来的诸多工程中。感谢同学对课程组提出的意见！

包装类以及整体结构的设计很不错；不知道有没有考虑过在包装类中引入基本的查询逻辑，而非将所有查询逻辑全部写在顶层类？ 对于测试机的描述很有创意 架构也确实很不错 厉害了 代码规范、面向对象思想等实际上都是撰写一个大型可维护工程的必要工具；希望通过这门课程的学习，同学们能够在今后的代码生涯中积极运用并实

分类器+builder这种把各个业务分离+串联起来的想法非常不错；可以了解下流式编程，说不定会对这类设计有所帮助 解耦合确实可以在多人协助中极大地提升效率；或许这也是面向接口、面向层次等思想在今天如此流行的原因之一。 抗压对于OO来说确实也很重要[笑哭] OO的压力确实很大 以及说实话就差一名 真的

虽然代码设计上看起来不是严格的代理模式，但这种封装的方式在第四单元中确实很有用处； OO的课程压力确实相对较高，相比于之前的课程在任务量、评测难度等方面均有所提升。某位老师也曾在上课时口胡过“我们的第一单元相当于某学校的期末作业还多”这种（ 如何去分析、解决问题是面向对象编程中很重要的一部分，但还不

前两次架构稍显暴力了；循环继承可能确实没什么特别好的解决办法。 第三单元确实压力较小，不过这也是考虑到隔壁OSLab4 😃 OO这一门课程确实压力不小，任务量和评测强度比起之前的课程来说确实是上了一个档次；不过正如文中结尾所说，我们诚挚的希望每一位参与课程的同学都能在课程中有所收获，无论是接口继承

OO课程的整体过程中很重要的一部分便是体验（相对而言）大型软件开发的过程，并从中汲取面向对象以及这之上的抽象的编程经验。 正如文中所述，OO不局限于java，而是无处不在；就连友商OS课程中也能够体会到这种思想（文件系统、netif、模块机制等等）；希望同学们之后的代码生活中能够体会到这种力量，并且

因此希望课程组能更加严格地把控分享的质量，宁缺毋滥 我对“宁缺毋滥”的想法感到很有兴趣，还请你能进一步说明一下，如果发生了“缺”的情况，你觉得可以用什么形式来继续进行研讨课的分享呢？这将对OO课程组有很大的参考价值。

搭建评测机是锻炼系统能力的好机会，只是我个人不是很推崇，毕竟测试能力的核心不在于拿随机数据狂轰滥炸，而是精准把握边界条件。 当然，我相信你在数据构造上付出的辛劳一定不少，也相信你已经从中获得了很多的经验积累，这对于后续学期中同学们将要面临的更多软件项目的编写有极大的作用。继续加油。

测试实际上是完善的开发流程中必不可少的一环；虽然OO课程中引入测试确实加重了同学们的负担，但在未来的开发中测试时不可或缺的。 架构与规范、抽象与继承，OO课程其实为如何撰写大型程序指明了路径。希望同学们能够在今后的编程生活中，继续实践OO所传递的思想~

另外补一句 你的博客在总结上做的很好，逻辑清晰，让我能够清楚地了解OO课程为你带来了什么新知识与新启发。 我相信你是真真切切地从OO中获得了如上的这些提升的，同时我也相信这并不是“内卷”带给你的，而是你对OO课程由衷的喜爱与认真带给你的。继续加油。

我觉得同学们把大量的时间花在找其他同学们的错误上真的是一种内耗……如果能用这些宝贵的时间系统性地学习一些新的知识，比如就简单的阅读一本《设计模式》大黑书，该多好啊！ 阅读其他同学的代码来找BUG确实能够为学生带来收获，这不是我的臆想，因为我也曾是OO课程中的一名学生。至于是选择获得这种收获，还是去读

我觉得你的博客在对技术的理解与阐释上做的很好，也很敏锐地认识到了本学期接触到的一切知识都只是开始。我很期待你未来的学习与发展。 希望课程组能对搭建测评机和进行单元测试给出具体的指导。 我个人不是很希望引导同学们搭建测评机，因为这不是培养代码测试能力的核心问题所在。而单元测试的话，我们应该有提供足够的

我觉得测试占编程的50%，不会测试的程序员就像是瘸了一条腿

个人认为第一、二单元的难度远超三、四单元，可以考虑将第三单元(JML)改成第一个单元，不至于让大家在第一单元就被重击 OO与OS课程组向来保持着密切的交流。OS Lab循序渐进的特点导致其前期压力较小而后期逐步发力，因此OO课程组历年来都尽量避免高难度的单元与OS的高难度Lab重合，以最大程度地降低

将不同业务放在不同的类里进行处理是很不错的抽象思路； 第一单元在设计的时候就有在第二次作业去卡架构的想法，这样看来倒是达到目标了（ 第三单元的架构方面确实比较弱，可能需要一定的改进。 测试实际上是完善的开发流程中必不可少的一环；虽然OO课程中引入测试确实加重了同学们的负担，但在未来的开发中测试时不可

对中测难度进行一些合理的调整…… 我觉得有必要就该问题进行一定的说明：中测难度是经过慎重考虑的，而且就目前来说，我们后台统计数据分析显示，目前的中测难度恰好能够保证中测通过率和强测通过率的平衡。 我们不能为了让“懒得自己做测试”的同学获得更高的强测分数，而牺牲其他及格线附近的同学获得有效作业次数的权

对于工厂类、共同父类的设计很精妙也很OO； OO课程确实整体而言是很强调架构设计的；希望在这门课程之后，同学们能够更加注意自己的架构，写出可维护性，可拓展性更强的代码~

将不同业务单独独立到不同类中确实是不错的想法；MyElement类的做法也非常OO。 U4的指导书确实有些地方表述还可以精确化，我们也在尽可能地逐年完善指导书，争取解决同学们的阅读问题~ 如果同学们在这门课程之后能够开始重视自己的代码结构，用心呵护自己的代码，那我觉得这门课程一半以上的目标就已经达到