首页 > 代码库 > 结对项目-地铁出行路线规划程序(续)

结对项目-地铁出行路线规划程序(续)

 

关于结对编程

  • 结对编程对象:冯炜韬。

 

 

  • 结对编程的优缺点:

    优点:程序员互相帮助,互相教对方,可以得到能力上的互补。增强代码和产品质量,并有效的减少BUG。在编程中,相互讨论,可能更快更有效地解决问题。

    缺点:对于有不同习惯的编程人员,可以在起工作会产生麻烦,甚至矛盾。面对新手,有经验的老手可能会觉得非常的烦躁。不合适的沟通会导到团队的不和谐。
  • 对方的优缺点:

    优点:技术强,经验丰富,涉猎广泛,对各个领域都有所了解,智商高。

    缺点:
  • 自己的优缺点:

    优点:有时候很勤奋,热爱编程,喜欢钻研技术。

    缺点:有时候也很怠惰,经验不足。

 

关于设计方法

在开始编程前应先设计好自己程序的结构,包括各个数据的访问控制、模块的接口设计和模块之间的关联交互。在设计和确定模块时,使得一个模块内包含的特定信息(过程或数据),对于不需要这些信息的其他模块来说,是不可访问的。而其他模块若必须获取某些信息,应该只能通过给定的接口进行访问。各模块的交互同样也应只在指定的接口下进行。接口的设计有各种原则,如单一职责原则,接口隔离原则等。

耦合是模块之间依赖程度的度量。耦合的强度依赖于以下几个因素:(1)一个模块对另一个模块的调用;(2)一个模块向另一个模块传递的数据量;(3)一个模块施加到另一个模块的控制的多少;(4)模块之间接口的复杂程度。

一个类对另一个类的依赖应该表现成依赖尽可能小的接口,也就是低耦合性。
这个原则是用来处理胖接口的缺陷,避免接口承担太多的责任。比如说一个接口内的方法可以被分成好几组,分别为不同的客户程序服务,说明这个接口太胖了。当然,确实也有一些类不需要内聚的接口,但这些类不应该做为单独的类被客户程序直接看到,而应该通过抽象基类或接口来关联访问。

Design by Contract

Design by Contract即规格化设计。规格化设计是一种软件设计方法,它规定了软件设计者必须为软件的部件定义好标准、精确、可验证的接口规范,它在通常的数据类型抽象的基础上扩展了前置条件、后置条件及不变式。
规格化设计方法认为所有的用户程序在请求系统服务时都需要满足前置条件,具体来说也就是操作的REQUIRES。在多线程或者分布式计算中,这样的假设是有一定危险性的,所以此时采用防御式设计方法,也就是在系统响应时对所有相关前置条件进行测试。并且在不满足条件时抛出适当的错误信息。

规格化设计的核心思想是对软件中的元素如何在“责任”与“义务”的基础上进行协作的比喻。这种比喻从商业活动中“客户”与“供应商”达成“契约”而得来。在面向对象程序设计中一个类的函数提供了某种功能,那么它应该可以:

  1. 期望所有调用它的客户模块都保证一定的进入条件:这就是函数的前置条件—客户的义务和供应商的权利,这样它就不用去处理不满足前置条件的情况。
  2. 保证退出时给出特定的属性:这就是函数的后置条件—供应商的义务,显然也是客户的权利。
  3. 在进入时假定,并在退出时保持一些特定的属性:不变式。

当使用规格时,供应类不应验证是否满足前置条件。大体的思想是,利用规格条件校验为保护网,在规格被违反的情况下代码会崩溃(fail hard)。规格化设计让调试变得简单,因为每个过程的行为意图被定义得很清楚。它和防御式编程方法明显不同,在那种方法里,供应类要负责解决前置条件不满足的情况。通常情况下,在规格化设计和防御式设计中,如果客户类违反了前置条件供应类都会抛出异常—由客户来负责解决这种情况。规格化设计让供应类的工作更简单。

规格化设计同时也定义了软件模块的正确性条件:

  1. 如果在调用一个供应类之前类的不变式和前置条件为真,那么在调用后不变式和后置条件也为真。
  2. 当调用供应类时,客户类应保证不违反供应类的前置条件。

规格化设计也能帮助代码重用,因为每段代码的规格都被很好的文档化了。模块的规格可以被当做软件文档来描述模块的行为。

unit test

技术分享

测试结果:全部通过

实现算法

关于路线查找的算法都很简单,原来的-b和-c功能只要把边设为一个二元组,把不同线上的同一个站分裂成每条线上一个并且之间用(1, 0)的边相连,正常的站之间用(0, 1)的边相连,-b时以第二元为键,-c时以整个二元组为键做dijkstra即可。-a的算法是先预处理任意两点间的最短距离,然后每次选择一个尚未走过的点从当前点以最短路走到目标点,选点时注意不能当前点和目标点之间不应有其他未选点。

结对项目-地铁出行路线规划程序(续)