标签：OO 层次化 作业 summary 构建 Unit 模块 单元
Unit 4博客&课程总结
Unit 4作业的架构设计
本单元作业的设计我分为了三个模块处理：模型构建 + 预处理 + 任务函数，前两部分即为整个图的完整构建，第三部分即为实现题目要求的查询方法。
最终的文件树如下图所示：
模型构建
为了便于对于一些属性的查询以及避免与官方包内的数据类混淆，我为题目中遇到的每个UML元素都构建了自定义类，在拷贝过原有的属性后，另外新增了一些过程量表示模型图结点间的关系。以 UmlClass 为例，我构建了 MyClass 类。为了表示类图中的属性、方法以及其他一些中间变量，我构建了相应的容器并配备了查询方法。
除此之外，对于整体图模型的解析与构建，我采用了层次化解析的思路，即从上到下依次解析。例如对于类图元素，先解析图中的结点（类与接口），再搭建类图中的关系、补充结点信息（继承、关联、方法等），以此类推。层次化构建使过程非常清晰，且可扩展性也非常好。
预处理
因为本单元的任务完全是静态查询，数据在输入后不会发生变化，因此为了减少查询时的时间复杂度，我对一些变量采取了预处理的办法，在执行完模型构建后调用相应的 update() 方法。例如对类的继承深度 depth、类的间接属性、类实现的全部接口（包括直接与间接）等。
任务函数
任务函数即为预处理后对相关的数据的查询，这部分的具体实现内置在每个自定义类中，不必详细介绍。
三个模块完全依次执行，相互独立，耦合度低，且可扩展性很强。
架构设计思维及OO方法理解的演进
架构设计
架构设计是OO课程中不可或缺的一环。以往程序设计的题目只是解决一个小问题，我习惯于拿到题目后直接上手，遇到问题时再去想怎么解决；但是OO课程每一个单元的作业更像一个完整的项目，代码动辄几百上千行，要想避免让代码变为屎山，就要求有一个清晰、可扩展的架构。因此在每个单元作业前，我都会预留思考的时间，仔细想想需求的层次、模块的设计、以及可能的扩展方向，力求在将来的增量开发中有更好的体验。
像在第二单元的线程安全的设计中，我反复琢磨可能发生死锁的情况，对执行 wait() 方法的模块反复推敲，取得了良好的效果。
在第四单元的作业中，在拿到题目后，层次化解析UML元素、分层架构的思路就已经浮现在脑海了，我将所有的元素分为5层进行解析，先是类图、接口、顺序图，再是他们中的属性、方法、消息等，很快就完成了作业，足以见得架构设计给我带来的帮助。
OO方法
面向对象中封装性至关重要，是面向对象的灵魂。OO将需求拆解为各个模块，通过完善模块内容与处理模块间的交互来完成需求。这样的好处是：
-
层次化清晰，每个模块解决自己的活，分工明确，同时也降低代码的耦合度，利于维护与更改；
-
增强可扩展性，需求变化后只需更改相应模块的内容即可解决；
-
复用性强，模块作为一个整体可被反复调用；
测试方面
OO课程中的测试环节我都是按照以下流程进行：
-
利用样例代码与自己手动捏的较弱的数据进行测试，保证基础功能的完成；
-
针对易错、易超时的方法针对性构造数据强测，如Unit 3中图论的一些方法等；
-
与小伙伴对拍，利用大数据覆盖性测试。
在第一单元中，我没有使用测评机，均是采用上述一二步骤进行测验。由于构造测试样例的疏漏，我没有考虑构造输入为0的情况，导致在第二次作业中强测被扣了分。
在第二单元中，针对电梯请求的构造，我利用测评机生成覆盖性数据进行本地强测。但是可能由于测评机不够完善，导致在第二次作业采用共享队列时被hack了。
针对第三单元的JML测试，我用不惯Junit，实际上还是针对方法自己构造测试数据。因此还是采用了针对图论方法构造可能超时的数据进行测验，第三单元强测均满分。
第四单元细节繁多，的测试主要以和小伙伴对拍为主。先用超大数据进行强测，而后生成对应的针对性数据找bug，效果不错。
课程收获
-
学会一门新语言——OO课程帮助我了解了java，不仅包括基础的java语言，还包括UML类图、JML规格等。通过第一到第四单元的作业，我已经能够熟练使用java编程，并轻松地debug；
-
一帮好友——OO课程作业设计十分巧妙，有许多值得推敲的点，上到架构的设计、模块的构建，小到具体算法是实现，都是值得讨论的地方。在于他人交流的过程中，我感受着思维的碰撞，与同学们相互交流，也让我结实到了许多优秀的同志；
-
对于层次化架构的理解——设计层次化的架构是面向对象编程必不可少的环节，简约、清晰、易扩展的架构能节约很多时间。在拿到需求后设计模块、理清楚逻辑关系是首要环节，否则很有可能在后期的迭代开发中面临要么重构，要么堆屎山代码的选择。层次化架构的分析不仅是OO的一种思想，也是一种人生哲理啊！这告诉我们切勿想着一口气吃个胖子，要做好规划。
改进建议
-
我认为寒假的预习板块可以改进一下。可以看出该部分是为了承接第一单元表达式计算的作业而设计的，花费了很多篇幅去讲解正则表达式的格式以及UML类图的设计，但是花费一个单元共5讲的内容来介绍正则表达式有些冗长。我认为可以将第三弹的内容进行压缩，达到熟悉正则的目的即可，并相应地增加一个预习第四弹，可以介绍一些常见的设计模式（如工厂模式、单例模式等）。OO课程的目的最终还是培养面向对象的思想、架构设计能力，这样也可以契合培养方案。
-
我认为对于讨论区以及微信群的交流与答疑方式可以改进。据实际体验而言，微信内的答疑效率非常低下，许多人不翻消息记录，会有大量的重复提问；讨论区的相关板块十分杂乱，没有索引结构，助教老师回答采用 “引用原话+回复” 的方式不够清晰，导致在“针对指导书提问”这一个栏目给人观感十分臃肿、不清晰。我认为可以将一些针对指导书内容的提问局限在讨论区，微信群仅用于其他交流，再为规范讨论区的结构，建立清晰的索引结构，提高同学们提问、查找的效率。
-
研讨课上一些内向或摆烂的同学不积极发言，全程混讨论，没有自己的观点，享受他人思维碰撞的果实，这是不公平的。我认为可以对研讨课环节分数的评定进行一些细化，如会议纪要中写出每个组员贡献的思想并以此评议每个人的分数，再根据小组代表发言的内容进行小组加分，细化为个人与团体分，可能大家积极性会高一些。
标签：OO,层次化,作业,summary,构建,Unit,模块,单元 来源： https://www.cnblogs.com/GreenDragon/p/16417419.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。