First, the architecture of this unit
1. FIG class
the first time
the second time
2. Description of key approaches and architectures
Just goes to show the results of the calculation are read when the general view of most computing time to complete (complete cache), call query method, a small number of direct calculation. It is to design a variety of their own class definition, creation and completion of various types of input data into a container processing. The second operation, using a pre-processor for UML elements were entered multiple passes, first create a specific object, and then create a secondary dependent objects, and then read the relationship between a particular method of creating an object while before calling, so realize the information entered regroup in order to meet the requirements of the inquiry. Thus each of the functional units is, more favorable development and testing.
Second, the architecture design and understanding of the evolution of OO methods
When the first unit, thinking of architecture is not very deep, just do extract from the task required in different objects, and consider the message passing between them. This is my beginning to understand object-oriented methods. At that time the establishment of objects and classes can only take into account the function can be realized that this is a program written in a different, more intuitive approach. But it did not take into account the security of the code, the clarity of the division of labor, scalability and reusability. From the third job, obviously you feel the code is almost complete reconstruction, spent a lot of time to start considering not only realize the function, but more considering whether to better support more features, if you can go long.
The second unit further deepen the understanding of the object-oriented approach in multithreaded programming perspective. In this module, I realized that for scalability and reusability of choice measure. In some places you can retain high scalability, because there are a lot of extensions may, for example, in the first two is bound to consider the multi elevators, which is very common in the real world. And third, the elevator-specific floor design does not need to be very scalable, as closely related to a particular floor of the building features an elevator, not very common, so the scheduling rules and programs designed better, do not trouble write very universal scheduling method.
第三单元中由于我的实现方法是在输入时计算，查询功能只是输出计算的结果，因此需要注意数据的安全性。即查询的时候应该不改变任何存储的数据，或者计算某一个数值时不应该改变其他的数值；我主要使用的方法是Floyd算法以及其变体，于是在架构设计层面使用了工厂模式来实现，使得代码拥有较为安全的可扩展性。因而在实现一种查询任务之后，其他的查询都是类似的，编写起来十分轻松。但本单元中，需要注意的是，无论是JML的使用还是面对对象方法的使用，虽然保证了正确性，但是未考虑到算法的时间复杂度和空间复杂度，这一点需要单独考虑和处理。
第四单元中，面对稍大的工程量，我主要按照功能进行封装，并增加了自己的类结合继承和接口来实现特定对象的搜索功能，从而快速处理数据。本单元中，我主要把任务分解为输入、检查和查询三部分，分别调用实现相应功能的专门类对输入进行处理，从而使开发单元化。
总体而言，经过一学期的学习，我对架构的思考、面向对象编程的方法，有了质的飞越。
三、测试理解和实践演进
最开始的时候，对测试的理解以及测试数据、测试方法、调试方式比较简单和单一。最开始认为只要程序运行的过程中不出现bug就是测试的目的（面向评测机的DEBUG），构造的测试数据以边界条件为主，使用的测试方法只是run或者辅以printf的调试方法。
通过第一单元后，开始编写数据生成器、对拍器等方法来创造测试数据，并开始使用JUnit进行单元测试，使得测试模块化，减少了测试使用的时间。同时开始使用条件断点、分级测试的理念进行调试，并开始关注代码的覆盖率等，更好地利用其调试的信息，从而使得出现bug后定位到错误代码的时间大大减少，提高了测试的效率和质量。
第二单元时，学习了多线程编程时不同的测试方法，不仅了解到多线程的断点使用，也体会到了不可复现性对测试带来的挑战和不安全性的引入。
第三单元是，接触到JML，体会到规范化对代码分工和测试带来的便利和好处，同时本单元开始考虑时间复杂度，不仅仅在功能上进行测试，也要考虑使用算法的时间和空间性能。测试数据的编写更加全面化，分别有覆盖多功能的数据、针对不同实现方法的最差情况最高时间复杂度的极端数据和空间复杂度较高的数据（本单元中对空间复杂度的限制较低，因而没有特别的关注）。
第四单元明显感受到测试数据编写的麻烦，没有详细设计实现一个较为方便的测试数据生成系统，主要靠徒手造，这使得测试数据的完整覆盖与否完全体现在是否充分理解指导书上。本单元更多的收获是在理解用户需求的层次上。
总体而言，我的编程的总体思路、测试数据构造、测试的方法、调试的方法等方面经过一个学期的学习都得到了非常大的完善和进步。
四、课程收获
首先是对面向对象编程和JAVA语言有了更深刻更全面的理解。在大二上学期时，我也选择了JAVA课程并得以自学和自行摸索，通过这一学期的学习对我自己构建的知识系统有了比较好的修正和补全。现在回过头来看大二上学期时写的大作业（一个多线程的游戏），发现从类属性的隐藏、线程安全性等小问题到代码整体的架构、耦合度、圈复杂度等等来看都漏洞百出、“不忍直视”。
简单分析，当时写程序时考虑问题简单，没有考虑到安全性、代码可维护性、代码可扩展性，测试也不够充分。经过一学期的学习之后，首先在写程序的时候增加了提前架构思考和完成后测试调试的过程，而不仅仅把大部分时间放在写代码上；在写属性或者创造新对象时，现在会注意隐藏和使用创造模式，来增加封装和安全性，这使得多人分工合作或者自己一段时间后再来编写代码的时候不至于不小心修改了不应该修改的部分从而引入错误。原先代码比较冗长，耦合度高，分类的逻辑更像目前folder的逻辑，或者仅仅是太长了所以分出来一些，没有考虑到业务逻辑，也没有考虑到可扩展性、代码重用等角度。目前会在编写类的时候更多考虑奥卡姆剃刀法则，同时使用继承、接口来增加代码复用。多线程编程中，了解了比较经典的生产者-消费者模型，包括在OS课程上所学的哲学家进餐、银行家算法等，对线程的安全性、死锁有了更好的理解，大大降低了多线程中出现BUG的可能性。以及对于代码风格的重视，使得起类名等更加简洁清晰，同时方法行数太多是就会自觉思考是否架构方面可以更优，以及访问是否可以是package可访问、是否可以使private的来提高安全性。我感受到遵守代码风格不是一件麻烦和多余的事情，而的确会提高代码的可阅读性、清晰性和架构的合理性。
五、关于课程的建议
1.强测部分中，某些次作业建议考虑功能和性能分别测评。如果使用较为复杂的优化方法，有可能会导致引入潜在的错误或者CPU超时等，虽然这是学生需要注意的地方，但是对大多数学生而言，往往会为了求稳而完全放弃优化，积极性得不到鼓励。
2.目前课程网站已经有非常好的功能，但吹毛求疵来说，有些易用性方面上的不足，具体有以下建议：
如图，虽然学期中的时候增加了返回所有作业这一按钮，但整体而言使用起来还是不太方便。建议在评测、互测这一行最左端增加下拉式菜单等类似的切换课程的按钮，以便方便地切换历次的作业（顺便，作业的题目中可以适当增加关键字，如UML、电梯，目前仅仅是第x次作业，不太直观）。
讨论区感觉使用这种筛选方法不太方便，可以借鉴传统网络论坛中分区设计，设置“官方回复区”、“提问区”、“讨论区”之类的可能会更加易于使用。
3.有关课堂的分享交流和课程提供给学生的自由度角度来讲，感觉可以考虑增加一次自由度较高的作业，实现方式比较多，在课上学生们讲自己独特的方法。在后几次作业时，虽然难度不高，不过代码量较大、课业较为繁忙，学生基本上都无暇去研究和细看其他学生的实现方法（刚开始几次可能为了找BUG会仔细阅读，之后基本上就很少有人下载别人的代码了）。这有些遗憾和可惜。
4.建议以后在某单元的前两次作业指导书中适当给出之后作业的要求，让学生有目的地进行可扩展地编写。而不是仅仅为了AC本次作业而下次完全推倒重构，或者为了可扩展性而写得过于冗长复杂。而学生在进行下一次作业时，将会直观地感受到自己上次作业的可扩展性如何，是否真的能扩展了，还是仍需重构，从而加深这方面的理解。