Lab3之噩梦延续

这次比上次更恐怖，兄弟，我顶不住了，
更可怕的是，我竟然在ddl的最后一天，写代码写到校医院去了，我佛了
发烧加胃胀气，两天没吃饭，就喝一点粥，人都瘦了，不过这样，脸清瘦了，
头发也长了，似乎更帅了。

目录

1 实验目标概述 1
2 实验环境配置 1
3 实验过程 1
3.1 待开发的三个应用场景 1
3.2 基于语法的图数据输入 1
3.3 面向复用的设计：CircularOrbit<L,E> 1
3.4 面向复用的设计：Track 2
3.5 面向复用的设计：L 2
3.6 面向复用的设计：PhysicalObject 2
3.7 可复用API设计 2
3.8 图的可视化：第三方API的复用 2
3.9 设计模式应用 2
3.10 应用设计与开发 2
3.10.1 TrackGame 2
3.10.2 StellarSystem 2
3.10.3 AtomStructure 2
3.10.4 PersonalAppEcosystem 2
3.10.5 SocialNetworkCircle 2
3.11 应对应用面临的新变化 2
3.11.1 TrackGame 3
3.11.2 StellarSystem 3
3.11.3 AtomStructure 3
3.11.4 PersonalAppEcosystem 3
3.11.5 SocialNetworkCircle 3
3.12 Git仓库结构 3
4 实验进度记录 3
5 实验过程中遇到的困难与解决途径 3
6 实验过程中收获的经验、教训、感想 4
6.1 实验过程中收获的经验和教训 4
6.2 针对以下方面的感受 4

1 实验目标概述
本次实验覆盖课程第 3、5、6 章的内容，目标是编写具有可复用性和可维护 性的软件，主要使用以下软件构造技术： ⚫ 子类型、泛型、多态、重写、重载 ⚫ 继承、代理、组合 ⚫ 常见的 OO 设计模式 ⚫ 语法驱动的编程、正则表达式 ⚫ 基于状态的编程 ⚫ API 设计、API 复用 本次实验给定了五个具体应用（径赛方案编排、太阳系行星模拟、原子结构 可视化、个人移动 App 生态系统、个人社交系统），学生不是直接针对五个应用 分别编程实现，而是通过 ADT 和泛型等抽象技术，开发一套可复用的 ADT 及其 实现，充分考虑这些应用之间的相似性和差异性，使 ADT 有更大程度的复用（可 复用性）和更容易面向各种变化（可维护性）。
2 实验环境配置
简要陈述你配置本次实验所需环境的过程，必要时可以给出屏幕截图。
特别是要记录配置过程中遇到的问题和困难，以及如何解决的。

在这里给出你的GitHub Lab3仓库的URL地址（Lab3-学号）。
https://github.com/ComputerScienceHIT/Lab3-1171000322
3 实验过程
请仔细对照实验手册，针对每一项任务，在下面各节中记录你的实验过程、阐述你的设计思路和问题求解思路，可辅之以示意图或关键源代码加以说明（但千万不要把你的源代码全部粘贴过来！）。
3.1 待开发的三个应用场景
首先请列出你要完成的具体应用场景（至少3个，1和2中选一，3必选，4和5中选一，鼓励完成更多的应用场景）。
 TrackGame
 AtomStructure
 SocialNetworkCircle
分析你所选定的多个应用场景的异同，理解需求：它们在哪些方面有共性、哪些方面有差异。
共性：
需要轨道系统中基本存在的对象，包括轨道、中心物体、轨道物体。其中物体都不考虑绝对位置。轨道都为圆形。

都需要完成的功能有：添加/删除轨道，在某一轨道上添加/删除物体，获得轨道系统的熵值，获得逻辑距离，比较两个同类型轨道系统的差异，检查轨道系统是否合法，可视化。
差异：
TrackGame需要构造多个轨道系统，而其他两个只需要从文件中读入一 个，需要编排。

TrackGame需要实现编排策略，需要实现对轨道物体交换组/轨道系统。	AtomStructure轨道物体都是值相同的对象，需要实现物体跃迁。	SocialNetworkCircle中需要实现物体关系及对应操作，需要计算信息扩	散度。

3.2 基于语法的图数据输入
通过正则表达式来读入处理得到，相应需要的信息。
下面为三个正则表达式：
TrackGame：

第一行的匹配运动员的信息
第二行的匹配几百米轨道
AtomStructure：

上面的第一个用来匹配轨道数目
第二行用来匹配中心物体

上面这个通过轨道数目构建正则表达式，匹配每个轨道上面的电子数目
SocialNetworkCircle：

第一个用来匹配中心人物
第二个用来匹配关系，
第三个用来匹配Friend
这些都在CircularOrbit的input里面实现匹配操作
3.3 面向复用的设计：CircularOrbit<L,E>
类的域：

方法及其作用都在代码CircularOrbit<L , E> 里面了
其中包含一个内部类

作用相当于一维数组
3.4 面向复用的设计：Track

Track里面只有半径和名字，保证了其不可变类型

方法就是两个简单的返回信息
3.5 面向复用的设计：L
Immutable类
通过继承CommonObject而来，这样的好处是方便后面的各种信息的调度，建立关系的时候，方便处理，没有了中心物体与边缘物体的差异。

3.6 面向复用的设计：PhysicalObject
Immutable类，继承自CommonObject，抽象类

方法：

3.7 可复用API设计

1.  计算轨道系统熵值。
   

通过获取轨道系统的熵值，每一条轨道上的物体数目/轨道系统所有物体数目作为p，使用entropy=-sigma(pi*log2(pi))公式计算轨道系统熵值。
2. 获取最短逻辑距离。

通过队列配合bfs，任取e1作为起点，搜索到e2，便结束了，
3. 获取物理距离：因为在三个应用中不考虑物理位置，所以不予实现。
4. 计算两个多轨道系统之间的差异：

编写Difference来充分实现上述函数，

3.8 图的可视化：第三方API的复用
本实验中使用Swing实现可视化功能
GUI思路：
先画一个控制面板，可以选择相应的功能应用

这里分为三个画布，最上面的画布，，中间的画布，和最下面的画布，
中间的画板同来实现，画轨道和物体的功能，上面的和下面的画版，实现功能如上。
其他更细节的功能，通过，右边再画一个画板实现。
这样GUI的构架就完毕了。

3.9 设计模式应用
请分小节介绍每种设计模式在你的ADT和应用设计中的具体应用。
实现的模式方法有：

这里是再PhysicalObject里面，实现的

这里的工厂方法模式，就是现有一个抽象的工厂和一个抽象的的物体，然后设置具体的A工厂，然后具体的A工厂里面生产具体的A物品，通过这种方法，能达到很好的扩展性。

这里采用的是build模式，通过build模式能够很好的控制管理，继承的具体的应用类，通过build，能够具体到每个应用类，一步步该干什么，让应用之间的耦合减小

这里采用strategy模式，能够很好的管理两种策略，

Context的运用，能够很好的决定策略的使用，并且，再后续的扩展性方面也特别的好。

3.10 应用设计与开发
利用上述设计和实现的ADT，实现手册里要求的各项功能。
通用功能：
左上角为熵值：

删除物体：

添加物体在特定轨道上

添加一条轨道：

删除轨道：

以下各小节，只需保留和完成你所选定的应用即可。
3.10.1 TrackGame

通过命令行的输入，可以达到，选择策略的目的。策略实现了分组，如下：

这里演示组内交换，

交换完毕，演示分组交换

交换完毕：

下图为通过GUI的按键，交换组内位置。

3.10.2 AtomStructure

通过删除物体，在另一轨道上添加物体可以实现，电子跃迁：

e11从第1轨道跃迁到了第6轨道。
3.10.3 SocialNetworkCircle

判断在哪个轨道上，查询几级关系：这里只需要在建图的时候，判断，物体在第几个轨道，就知道了，该物体的几级关系。

删除关系：把。轨道上的两物体的关系删除，，再重新画图就好了。
添加关系：添加两物体的关系，再重新构图，本来位于后面轨道的，可能到更前面的轨道。

上图为添加关系后，重新构图

上图为删除关系
查询逻辑距离：只要调用下列APIs的函数，就行了，用BFS遍历

查询扩散度：求扩散度，其实也是BFS，这里就是不用考虑原点，不经过，原点，其他经过的点全部列进来，就是扩散度了。

3.11 应对应用面临的新变化
以下各小节，只需保留和完成你所选定的应用即可。
3.11.1 TrackGame
增加一种策略，接力比赛

把四个人分到一个赛道即可，
3.11.2 AtomStructure
用一个新的来代替中心的原子就好了，这里采用的ElementSEt里面包括一个名字，和一个set来储存在其中的物体。然后在AtomSTructure里面吧中心物体的添加换成这个就行了。

下图为众多中心物体的结合、

3.11.3 SocialNetworkCircle

为关系增加方向性：在原来的实现中，无向边使用两条有向边表示，这里只需要改一下，添加/删除关系的时候只需要操作一条边即可。

忽略边：在读入边的时候，如果存在轨道物体向中心点的边则不操作，然后将其他所有的边加入，这里当然也包括了外层轨道到内层轨道的边，但是这里我们保留它，因为从实际应用角度出发，虽然一条边是从外层轨道到内层轨道的，但是在添加/删除关系之后这条边也可能变成内到外的边。

如何忽略？这里我们直接根据轨道的编号，如果发现是轨道数更大的点到轨道数更小的点，这时添加的边就直接忽略了。
如果是一开始的边的话，因为是严格根据BFS的单单向边搜索。所以，后面的点，外围的点是不可能扩展到内圈的点，故外围向内围的点，就自然忽略掉了。

忽略影响：修改visualizeContentPanel，不显示外到内的边。修改求扩散度的操作，忽略所有外到内的边。但是如果两点之间是外到内的边，两者依然是相连的关系，这点在面板上的删除边功能上有所体现。

下图显示的就是，在外圈添加一个Curry单位，然后尝试添加，Curry到中心点的关系，发现并不能添加，实现了单向变的忽略。

3.12 Git仓库结构
请在完成全部实验要求之后，利用Git log指令或Git图形化客户端或GitHub上项目仓库的Insight页面，给出你的仓库到目前为止的Object Graph，尤其是区分清楚312change分支和master分支所指向的位置。
4 实验进度记录
请使用表格方式记录你的进度情况，以超过半小时的连续编程时间为一行。
每次结束编程时，请向该表格中增加一行。不要事后胡乱填写。
不要嫌烦，该表格可帮助你汇总你在每个任务上付出的时间和精力，发现自己不擅长的任务，后续有意识的弥补。
日期 时间段 计划任务 实际完成情况
20190410 全天 把框架写了，然而写错了 完成的效果不好
20190415 全天 把框架改了，报告都读了几个小时 算是读懂了报告
20190423 全天 然后慢慢写API复用的系统，完成方法 写的还行，不过有点没有依据，缥缈
20190424 下午晚上 写了一下午晚上的测试 幸好测试都过了
20190425 下午晚上 然后开始写第一个应用真的难啊。还要临时学各种模式 模式学习困难
20190501 全天 疯狂写第二个应用 效率不高
20190502-20190507 写了5天 疯狂写第三个应用，然后发现前面写了好多漏掉的地方，再根据报告补功能，补方法，补GUI,临时学GUI真的难 然后就很暴躁了，太难了
5 实验过程中遇到的困难与解决途径
遇到的难点 解决途径
各种模式临时学，太难了。没什么方法途径

百度，然后疯狂看老师给的模式的样例。但是那个样例真的不好啊，又不详细。东一下西一下

报告太冗长了

读了很久很久的报告，光读报告，理解报告就用了少说10个小时

6 实验过程中收获的经验、教训、感想
6.1 实验过程中收获的经验和教训
学会了一些模式，学会了GUI然后，学会了怎么写APi了。
6.2 针对以下方面的感受
(1) 重新思考Lab2中的问题：面向ADT的编程和直接面向应用场景编程，你体会到二者有何差异？本实验设计的ADT在五个不同的应用场景下使用，你是否体会到复用的好处？
二者的差异就是，一个针对性更强，另一个比较方便套用
复用特别方便应用的嵌套，然后用起来比较方便。
(2) 重新思考Lab2中的问题：为ADT撰写复杂的specification, invariants, RI, AF，时刻注意ADT是否有rep exposure，这些工作的意义是什么？你是否愿意在以后的编程中坚持这么做？
我愿意这么坚持，看别人的代码是一件非常痛苦的是，尤其是还没有规格说明的时候，所以，坚持写规格说明，是一件非常重要的事
(3) 之前你将别人提供的API用于自己的程序开发中，本次实验你尝试着开发给别人使用的API，是否能够体会到其中的难处和乐趣？
难处，就是得自己考虑很多事情，乐趣就是苦中作乐
(4) 在编程中使用设计模式，增加了很多类，但在复用和可维护性方面带来了收益。你如何看待设计模式？
设计模式，就好像一个公式，更方便我们编程，就是挺麻烦的，不好写
(5) 你之前在使用其他软件时，应该体会过输入各种命令向系统发出指令。本次实验你开发了一个解析器，使用语法和正则表达式去解析输入文件并据此构造对象。你对语法驱动编程有何感受？
我觉得正则表达式很有帮助，以后会常用的
(6) Lab1和Lab2的大部分工作都不是从0开始，而是基于他人给出的设计方案和初始代码。本次实验是你完全从0开始进行ADT的设计并用OOP实现，经过三周之后，你感觉“设计ADT”的难度主要体现在哪些地方？你是如何克服的？
难度在于凭空想，框架没给出，太难写了，
(7) 你在完成本实验时，是否有参考Lab4和Lab5的实验手册？若有，你如何在本次实验中同时去考虑后续两个实验的要求的？
本来想参考的，后来发现读Lab3的实验报告就读不懂，后面的就没看了
(8) 关于本实验的工作量、难度、deadline。
工作量巨大，难度max，deadline其实还行，
(9) 到目前为止你对《软件构造》课程的评价。
感觉东西太多了，学的多，但是，很多学习，都是得自学，自己琢磨，如果老师能给更多的样例，方法，或者模板，学习会更好学一点。