标签：

组员：14061216 陈鸿超

         1406        程富瑞

一．结对编程分析

照片：

结对编程的优缺点：

优点：

1. 毫无疑问，两个人在一起解决一个问题想法更多。比如这次作业站点坐标的确定，之前一个人的时候，想法是手输或者写个算法自动计算，当然这个算法就会很难，不一定做的出来。而两个人在一起商讨时，他突然找到了一张北京站点的经纬表，看到这个我就想到了找一个站点做为中心点(0,0)，再找两个最远站点，这样根据他们三个就可以换算出所有站点的坐标。很准确，而且最重要的是简单多了。
2. 分配好任务之后，每个人的工作量就比较轻了。
3. 互相借鉴学习对方的编码风格。

缺点：

1. 自己的一些想法不能快速准确的传达给对方。
2. 就这次而言，我们两个人都通读了完整的代码，在看到对方代码时效率难免有些低。
3. 毕竟编程时不在一起，沟通起来有些麻烦。

个人优缺点：

二．如何利用好的设计方法

Information Hiding

　　对于信息隐藏，应该在数据建立的阶段就创建一种规则，使用一些ID来代表这些数据，当然也要记录下ID与相应数据的对应关系。在后面的操作中，对输入都可以转换为ID，然后对ID进行操作，输出也用ID表示。只有在最终展现给用户的阶段才将其转换为具体的数据。

Interface Design

　　接口的设计包括两个方面，一个是在编程时为了规范功能相似的类而定义的接口，这类接口的实现重点在于总结出相似类的共同点，然后将共同点其封装在接口中，让这些相似的类都根据自身情况去实现这些共同点；另一方面的接口设计则是为了提供给测试和外部程序使用，这方面就要做好封装的工作，让每个功能都能独立运行，不依赖与其他模块，有正确的输入就能出正确的结果。

Loose Coupling

　　对于这一点，主要还是尽量的对各种功能，实现这些功能需要用到的一些代码都进行封装，各司其职，尽量减少功能之间的依赖性。让每一个功能模块在输入正确的情况下就能够产生正确的输出，而不关心其他模块是否正确。这样才能在修改某一功能时尽量不对其他功能的代码造成影响。

三．契约式编程

　　其实契约式编程在大二下的OO课上接触过，感觉他其实更像是一种编程习惯。按照契约式编程的要求，每个方法都得有明确的前置条件，后置条件和不变式，其实也就是明确他的输入、输出已经中间的实现过程。

　　优点：通过这种格式化的规定，使用契约式编程写出来的程序，每个方法都会非常容易测试、Debug以及功能修改。而且这样写出来的代码清晰易懂，非常方便以后的维护与功能升级。同时，在最初的编程过程中，只有确定好了这三个条件，代码写起来也会简单很多。

　　缺点：麻烦，这种编程方式限制了方法的灵活度，必需要按照这种统一的格式，有时候还会带来内存和时间的额外开销。

　　这我们的作业中，对于那些封装在内部的各种功能函数，我们没有使用契约式编程这种方式，因为这是我们内部可见的，对格式的要求不高。而在包装提供给外部调用和测试用的API功能接口时，我们使用了契约式编程的方式，前置、后置和不变式都比较统一，这样方便了对这些接口的理解与使用。

四．Unit test

五．UML

六．程序介绍

(一) 数据的读取

1. 首先我们定义了两个结构route和station分别保存线路和地铁站的相关信息。

2. 通过读取地图文件，判断并保存下各个线路包含的所有站点，站点的邻近站点，站点所属的线路等信息。

3. 因为要做界面，所以我们要确定各个站点的坐标。这一点我们是写了一个函数，以天安门东为中心，根据一个站点经纬度表换算出各个站点的大致坐标，得到一个坐标文件。然后读取该坐标文件保存各站点的坐标。

(二) 路线的计算

1. 最短路线采用的是广搜，从起点搜到终点之后再倒推出路线。

2. 对于最短换乘，是通过先遍历当前线路上所有点，没有的话再从当前路线上第一个点开始进行这样的循环，找到终点之后倒推出所有最少换乘，然后从中选择站点数最少的。

3. 对于偏好，我们是记录下之前调用-b和-c的次数，通过这两个数判断-g采用最短路线还是最短换乘。

(三) 异常的封装

1. 将文件错误，参数错误等分装成异常，在程序中抛出。

(四) 界面设计

1. 因为我俩都是小白，不懂GUI设计。从同学那了解到openGL最简单之后我们就选择它。不过还是因为第一次接触，做的有点丑。

(五) 对不同城市地图的支持

1. 对于不同城市，只有按要求提供给我们两个文件--地图文件和经纬度表，然后指定坐标的中心站点和两个边界站点。我们的程序就能够支持其他城市的地铁线路查询，不需要再做什么太大的修改。

结对项目博客

标签：

原文地址：http://www.cnblogs.com/14061216chen/p/5926309.html