HITLab3心得

一.CircularOrbit

1.1CircularOrbit接口

1.2ConcreteCircularOrbit实现类

1.3Track

1.4 Itertor接口

二.CentralObject

2.1CentralObject接口

2.2 AtomCenter

2.3 SocialCenter

三.PhysicialObject

3.1PhysicialObject父类

3.2 Athlete

3.3 Friend

3.4 Electron

四.APIs

4.1 CircularOrbitAPIs(逻辑距离和熵值计算)

4.2 CircularOrbitHelpers(可视化）

五.Applications

5.1 ConcreteAtomStructure

5.2 ConcreteSocialNetwork

5.3 ConcreteTrackGame

5.4 GameManger接口

5.5 Strategy模式的两种实现

六.Change

6.1 TrackGame

6.2 AtomStructure

6.3 SocialNetwork

七.感言

本文内容仅代表个人观点，如有谬误请在评论区或私信指出，本人不胜感谢

1.1

CircularOrbit接口定义了轨道系统中的共性方法。
1.返回ConcreteCircularOrbit实现类的静态工厂方法
2.addTrack（）:向轨道系统中加入新的轨道
3.deleteTrack（）：从轨道系统中删除一条轨道
4.addCentralObject（）：向轨道中心点加入中心物体
5.addTrackObject（）：向指定轨道上加入物体
6.CreateCircularOrbit（）：输入文件构建轨道系统
7.deleteTrackObject（）：删除指定轨道上的某一物体
8.getTrackObject（）：visitor方法，返回指定轨道上的物体集合
9.getCentralRelationship（）：返回与中心物体有关系的物体集合
10.getTrackRelationship（）：返回与指定轨道上物体有关系的物体集合
11.getCentralObject（）：返回中心物体
12.getTrack（）：返回Track集合

1.2

ConcreteCentralObject是上述接口的实现类，对子类中共性的方法予以实现，个性的方法返回null，在子类中重写实现。其ADT定义如下：

其中orbit为轨道集合，center为轨道系统中心物体（L为其中心物体的泛型），trackObject为轨道上物体的集合，其中E为轨道物体类型的泛型，Integer为其所在轨道的半径。按照设计的ADT实现轨道及轨道物体的增删改查方法（在实现visitor方法时采用防御式拷贝）。

1.3

Track为轨道系统中的轨道类，其ADT设计如下：

其属性仅有半径一项，且设计为private final字段来防止被外部恶意操作更改，方法定义了构造方法及visitor方法来方便实现轨道系统的功能。

1.4

Iterator设计模式。

Iterator接口中定义了3个方法，分别为next（），hasNext（），remove（）方法。其spec如下：

实验要求遍历次序为按轨道从内向外依次遍历，因此着重重写next（）方法。

next（）实现思路：首先现将orbit按轨道半径从小到大排序，之后遍历orbit嵌套遍历trackObject，若轨道物体所在轨道半径大小与当前轨道半径相等，则返回该轨道物体，并将计数+1，在下次遍历时从下一个物体开始。这样即可实现按轨道从内向外的遍历。

2.1

CentralObject接口中定义了轨道中心物体的共性方法，主要实现了Atom及SocialNextwork中心的静态工厂方法。并且每个中心物体都设计了两种静态工厂方法，分别返回空对象，和进行中心物体的构造。其spec及部分函数如下：

2.2

Atom轨道系统结构的中心物体为原子核，由于并未对原子核属性有特别要求，因此仅定义其元素名作为其原子核属性。未定义特殊方法。

2.3

SocialNetwork的ADT定义如下：

SocialNetwork的中心为person，因此定义其name，age及gender，字段都作private修饰保证其immutable的特征。
方法除构造及visitor方法外，重写了equals方法，当SocialCenter类中3个属性都相等时定义为这两个类相等，以便实现轨道系统的功能。

3.1

PhysicalObject作为轨道物体的父类并未设计属性，仅在其中实现了子类的静态工厂方法。

3.2

Athlete类为TrackGame轨道系统中的trackObject。其属性设计为name,age,nation,num,grade。全部设计为private final字段来保证其immutable的特征。其方法除构造及visitor方法外，重写了其equals方法，当两个athlete类属性全部相等时，我们定义为这两个类相等。

3.3

Friend类为SocialNetwork轨道系统中的trackObject。其属性设计为name,age,gender。设计为private final字段保证其immutable特征。此类同样重写了equals方法，重写方式同上。

3.4

Electron类为AtomStructure轨道系统中的trackObject。作为原子结构中的电子，并无特殊的区分属性。此类也重写了equals方法，由于Electron并无属性，故所有的Electron类都相等。

4.1

CircularOrbitAPIs中实现了轨道系统的熵值计算及逻辑距离的计算。

1. getObjectDistributionEntropy方法返回轨道系统的熵值，其实现思路如下：先用visitor方法得到轨道系统的trackObject，然后用.values获得其所有的轨道半径（可重复）。按如下规则遍历获得的集合，若此半径遍历过，则熵值增加量+1（eg.一个轨道上有3个物体则每次+1，+2，+3），若未遍历过则熵值+1.
2. getLogicalDistance方法返回两个物体的逻辑距离，实现思路如下：若两个物体都在轨道上，则先用visitor方法获得轨道系统的trackRelation，而后采用先广搜索的方式获得其逻辑距离。若一个物体为中心物体，则用visitor方法获得其CentralRelation，而后在其中进行先广搜索，返回其逻辑距离。

4.2

CircularOrbitHelper实现了轨道系统的可视化功能。由于此次实验要求使用外部库实现可视化，在一番筛选后，本人选择org.piccolo2d库实现可视化。
可视化思路：在读入轨道系统后，若有中心物体，则在中心坐标附上中心物体的name，而后遍历其track，按半径大小画出所有轨道，后按iterator方法依次遍历trackObject，在其所在各个轨道上标出该轨道物体的name。

5.1

ConcreteAtomStructure类是AtomStructure轨道系统的具体实现类，其ADT设计如下：

trackNum为电子轨道数目，centralRelation为所有电子集合（由于所有电子与原子核的逻辑距离都为1，为了便于APIs中的计算，故加入此数据结构）。其特殊方法实现思路介绍如下：
1.createCricularOrbit方法读入文件返回轨道系统，其思路如下：首先，用readalllines读入文件，之后应用正则表达式按给定的格式匹配，读入文件轨道数目，每个轨道上的电子数目和原子核，存入轨道系统的center，orbit及trackObject中完成轨道系统的创建。
2.transition（）方法实现电子的轨道跃迁，其思路如下：从指定轨道上删除一个电子，在目标轨道上加入一个电子完成轨道跃迁。
3.judge（）方法，判断轨道系统是否合法，对于原子轨道系统而言，即判断其电子是否满足每个轨道2/8/18的个数，且后一轨道未满，前一轨道应满（此处不考虑稳定电子对）

5.2

ConcreteSocialNetworkCircle类是SocialNetwork轨道系统的具体实现类，其ADT设计如下：

friends为文件中读入的所有人物集合，socialCenter为该轨道系统中心person，centerRelation为与中心人物有直接社交关系的Friend集合，trackRelation是每个trackObject及与其有社交关系的人物集合。下介绍其中个性方法的实现思路：
1.createCricularOrbit方法读入文件返回轨道系统，其思路如下：首先，用readalllines读入文件，之后应用正则表达式按给定的格式匹配，先将除中心人物外的所有人物存入friends中，然后遍历friends，嵌套搜索文件，将与每个friend有社交关系的trackObject存入map中，最后将该friend与map一起存入trackRelation中。而后采用APIS中计算逻辑距离的方法得到每个人到中心人物的逻辑距离来确定他们所在的轨道。确定完毕后，将每个friend及其所在轨道加入trackObject完成轨道系统创建。
2.judge（）方法判断轨道系统是否合法，遍历friends，若每个friend与中心人物的逻辑距离与他们所在的轨道对应则轨道系统合法。
3.ContrustRelation方法即为实现轨道系统构建时，调用APIS得到逻辑距离并完成trackObject创建的函数，在createCricularOrbit函数中最后也是调用此函数完成系统构建
其余还有一些deleteRelation，addRelation方法，仅需要在将相应的关系在trackRelation中加入或删除后调用ContrustRelation重新进行系统的构建即可，此处不过多赘述。

5.3

ConcreteTrackGame类是实现TrackGame轨道系统的具体实现类，其ADT设计如下：

trackLength是比赛跑道长度，tracknum是一场比赛的跑道数目，Athletes是所有的运动员（即trackObject集合）。其个性方法设计如下：
1.createCricularOrbit方法读入文件返回轨道系统，其思路如下：首先，用readalllines读入文件，之后应用正则表达式按给定的格式匹配，分别读入轨道数目和轨道长度存入tracklength和trackNum中，随后将所有的运动员存入Athletes中，并按序加入trackObject中完成轨道系统的创建。
2.GameManger方法为应用Strategy模式完成比赛编排的方法，该方法读入一个接口类型，返回该接口中定义的方法返回值。

5.4

GameManager为实现TrackGame的Strategy模式编排比赛而创建的接口，其中定义了一个manageGame方法分别由应用两种不同策略的子类来实现。

5.5

TrackGame轨道系统的strategy模式采用了两种策略来编排比赛，其实现思路如下：
1.直接采用Athletes中储存的athlete顺序来依次编排比赛，按一场比赛的跑道数目依次将Athletes中的athlete加入，并单独创建一个TrackGame轨道系统，并将此系统加入可视化的画布上，在将文件中所有的运动员都编排完毕后，再将画布打印到窗口上，以此在一个窗口上完成文件中所有比赛的可视化
2.按Athlete的年龄从小到大将Athletes中的运动员排序，随后按如上方法完成比赛编排及可视化。

6.1

TrackGame的需求变化具体为一个比赛可以变化为接力赛，即一个跑道上可以有最多四人的团体，所以在change中，我们将TrackGame轨道系统的trackObject由Athlete类，变更为Map<Athlete,List>team,team中存有每个Athlete和他的队员。

6.2

AtomStructure的需求变化表现为原子核可以由质子和中子等多个微粒构成，在实现时，我们在CentralObject中新建了Neutron和proton即质子和中子两个类，同时新建AtomCenterStructure来extend原AtomStructure，符合OOP原则，新的原子核ADT如下：

分别为质子和中子的集合，符合变更的要求。

6.3

SocialNetwork的需求变更要求在实现轨道系统创建时，只读入从轨道内向轨道外的关系指向，即创建有向性的关系，我们创建一个新的类ConcreteDirectedSocialNetwork来extend原类ConcreteSocialNetwork以符合OOP的原则。下介绍创建有向性的轨道系统思路：

创建轨道系统时，我们先将所有的人读入存在friends中，而后遍历friends，并以当前遍历的friend来遍历文件，若该文件中当前friend在前（即社交关系由此指出）则将另一个人加入其socialtie（设计为Map）中，最后将friend及socialtie加入trackRelation中，调用constructRelation方法构建轨道系统。

7 . 感言

在第一次看这个实验的指导书时，我就感觉到它的复杂度非同一般。并且由于此次实验并未给出框架，一切的文件结构和ADT都由自己设计，因此一开始给人一种无从下手的感觉。在开始编程时甚至大部分时间都在写写删删，不过在确定好类的继承和实现关系及每个功能在哪里实现后进度一下子就快了起来，自己在实现时也能感受到这样的结构对于编程思路及效率的巨大影响。而在随后的change中，为了符合OOP的要求，自己使用多重继承时，一下子脑袋里就浮现出了那颗一直画在黑板上的树，现在看来真是恰如其分。不用更改先前的代码，而是继承他们的功能来做新的工作，这样的编程模式在我看来真正将“继承”二字诠释到了极致，也让我明白了当今程序员的工作模式，真是受益良多。