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

姐妹好棒呀

@Chenrt

orzzzzzzz

@krr 自己确实之前忽略了异常重入会导致sp不指向KERNEL_SP - sizeof(struct Trapframe)，pageout的压栈也确实可能影响到sp，非常感谢提醒！！ 将handler的信息以及信号的分发放到用户空间确实可以大大简化内核，个人认为是一种更好的实现。谢谢指出！

「do_refill中sp不指向 KERNEL_SP - sizeof(struct Trapframe) 」的原因可能有这两点： C 函数 pageout 中发生了压栈，使 sp 变小。 缺页异常是在上一级异常处理过程中触发的，即发生了异常重入。 另外，使用一个用户空间的 wrapper（类似 _

看起来架构的设计很好执行了层次化思想，并和分层调度策略进行了结合。这是应得到鼓励的方面。同步设计方面，建议还是要尝试其他的办法，比如Lock机制，会带来更大的灵活性。附上的UML图存在一些问题，相信这个时候你自己应该能发现了：（1）类图中RequestQueue与几个线程类的关系不太准确，应该是线程

@BUAA-Wander 感谢！！共同努力，共同进步！

@知北游手记 收到，谢谢老师(*^▽^*)

@知北游手记 谢谢老师的认可！考期结束之后我会尝试梳理一下的，恳请老师多指正批评。

@nikkukun 搭建本地评测机足矣保证正确性，但很难验证程序性能是否符合题面要求。可能需要手写一个基准策略的代码？但这样又比较浪费时间；从逻辑上直接验证也不是很靠谱。

按照处理流程来阐述架构设计可以涉及具体的策略或技巧，如果再能围绕待处理的数据之结构关系阐述，则更便于理解你的架构（其实是有助于你对你的架构认识更深刻）。

根据你的总结，你第一次作业就做了一个很好的架构设计，第二次和第三次作业的改动很小。而你之所以做到这一点，是因为你遵照指导书给出的数据的形式化定义中蕴含的层次结构。这说明你从一开始就捕捉到了本单元作业的核心要点，值得鼓励。但是，你的博客总结似乎比不上你的架构清晰性，特别是，列出代码实现是败笔，破坏了博

通过一个单元的训练，总结发现了自己的提升，同时找到存在的问题，这是值得鼓励的。第一次作业的架构确实没什么好说的了，第二次第三次的架构明显有了质的提升，但是我注意到其中有几个类很“胖”，包含的方法很多，仅从方法名称来上看，内聚度不是那么高。我想这也许是你需要进一步思考的地方。

体会到架构设计的重要性是第一单元训练的一个重要目标，恭喜你。什么是好的架构？这是一个非常好的问题。可扩展性确实是其中的一个重要方面，但还有其他，比如简洁性、易理解性等。需要指出来，你的类、方法、属性命名很不规范，导致可读性不高，这需要改进......

整理的非常清晰，分析也很深入，所设计的架构层次关系清晰，是一篇值得推荐的好博客。 最后的建议也很中肯，你是否愿意来做这个工作呢？比如从你自身体会角度，梳理出必要的辅导资料，我会根据具体情况把相关内容纳入到课件和pre中。

不知道你看了第一单元总结课对于层次架构的分析之后，对于你的设计有什么感想

博客结构清晰，论述比较清楚。 第一次作业的接口使用是个好的实践，虽然getHashMap操作是个败笔（不可以把一个类管理的内部容器结构反馈出去，应该选择返回外部关心的内容，比如通过iterator来访问），重构之后就好了很多。

虽然把你代码实现的主要内容写出来了，但是博客作业的主要目标是在架构整理、测试方法、心得体会等方面进行总结分析。

虽然你的设计带有很强的过程式设计思路（但是穿了很算得体的OO外套:-）），博客写的很细致，这个认真负责任的态度是要肯定的。 其实你从operator角度来进行抽象，基本完成了差不多2/3的面向对象设计，应该进一步向前，把operator作用的operand也纳入进来，然后封装成一个整体，再建立抽象层

你的设计思路是按照给定表达式的内在结构，从解析开始按照递归下降和"分支"策略来进行分派处理，并建立对象管理层次。这种处理带有全局主线流程的特点，是一种比较典型的以处理流程为主体的功能分解式设计，虽然能够完成作业的处理要求，但是从架构角度来看，显然不太好，局部方法复杂度高，类之间的关系较为复杂。其关键