首页 > 代码库 > 结对项目-地铁出行路线规划程序(续)
结对项目-地铁出行路线规划程序(续)
Github地址:https://github.com/qingchanghan/WPFUI_Metro
一、结对编程情况简介
1. 结对编程小伙伴:石浩然:http://www.cnblogs.com/shhr/ 陈彦吉:http://www.cnblogs.com/ChildishChange/
2. 结对编程大致流程:代码复审-代码调试-模块化-UI开发设计-异常处理-单元测试。照片如下:
3. 结对编程优缺点
- 结对编程优点:有时候项目规模比较大,如果一个人来写,程序的逻辑可能经常会出错。但是两三个人在一起,一个人错了有另外两个人提醒。代码质量会很高。另外,在学习一些新东西的时候,一个人可能摸索半天还不懂,但是两个人可能就理解起来更容易一点。毕竟“三个臭皮匠,顶个诸葛亮”。
- 结对编程缺点:两个人毕竟同时只能做一件事,有些简单的东西两人一起完成还没有单独完成效率高。
4. 小伙伴们的优缺点
- 石浩然:提供了效率很高的算法,研究学习能力很强,下了很多功夫。缺点是之前的代码结构有些混乱。
- 陈彦吉:代码结构和风格很漂亮,比较细心认真,撰写了公共部分的博客。缺点是有时候耐心不足。
- 韩青长(我):思路较为清晰,处理了很多边角问题,对项目比较积极。缺点是钻研心不足,技术方面略差。
(以下部分来自队伍公共部分)
二、设计方法
- information hiding
当开发一个完整的程序时,可将程序的每个组成部分封装在一个模块中,每个模块尽量少地对外展示模块内部的数据与对数据的处理,以此提高代码的复用性、可维护性。减少外界可见的信息,以保持模块的独立性,以此降低耦合。
从具体实现来说,我们确保某些成员变量和功能为private,并尽可能保证高层类只会调用底层类中特定的几个可供外界访问函数,而将其他方法封装在内部,限制了高层类对底层类的调用。
遗憾地是,我们这次在这方面做的并不好。类中大部分成员都是public类型。由于时间关系和代码结构上的问题,我们也没有进行大规模的修改,只是尽量改了一些部分。以后在这方面一定要努力。(回想起了OO课上教主强调的所有属性都必须为private。。。)
- interface design
据队友收集到的资料,接口设计共有六大原则。分别如下:
1.单一职责原则:根据实际需求划分职责,尽量做到职责单一。
2.里氏替换原则:所有引用基类的地方必须能透明地使用其子类的对象。
3.依赖倒置原则:高层模块不应依赖底层模块,两者都应依赖其抽象。抽象不应该依赖细节,细节应该依赖抽象。
4.接口隔离原则:接口尽量小,不要建立大接口,同时接口中方法尽量少,将接口隔离起来,将整体框架进行有效划分。
5.最少知识原则:跟information hiding有异曲同工之妙,此原则的使用可以降低程序耦合。
6.开闭原则:一个软件实体如类、模块和函数应该对扩展开放,对修改关闭,编程前对不同的模块确立明确的逻辑分工,为变化预留位置。
上面这些原则好像已经把如何利用讲的很清除了,我觉得实际应用中,第一条单一职责可以为模块化提供便利,然后里氏替换原则保证了继承时的正确性,第四条则对我们的设计能力和编程能力提出了很高的要求,重点还是以后要多注意这些原则,多用才能会用。
- loose coupling
尽可能全面地把握耦合度的高低,平衡好耦合和内聚程度,以确保可读性、服用性、可维护性的提升。不可一味强调低耦合,例如程序中发生变更概率很小的地方,不宜强行低耦合。还有程序中一些为大函数服务的小函数,小函数本身是依附大函数存在的,本身不会和其他模块建立过多的依赖关系,此时在耦合度上最好也做相应折衷。
三、Design by Contract与Code Contract
契约式编程:design by contract把类与被调用类之间的关系看作契约,规定了双方的权力与义务,这一方法被认为是构建OO软件系统方法的核心。
另外,我们通过一些知乎回答了解到的契约式设计:
1.目的:在设计程序时明确规定一个模块单元在调用前后应当处于何种状态,属于一种设计风格或是语法规范。
2.思路:强调前置条件、后置条件和不变式,当违反这些操作时程序会抛出异常。
3.优点是:契约式编程使代码标准化、规范化,提高了程序工程化程度。同时,对于测试者,在我们这次作业中,我们通过在不满足前置条件的情况下抛出异常,便于测试者测试。
四、Unit Test
- 简介:单元测试覆盖了Program.cs中的大部分函数,剩余的函数也基本在这些函数的调用中。测试不仅给出了正确的数据,还给出了错误的数据来判断异常是否能被捕获。
- 截图
- 有关覆盖率:由于VS 2015不再支持覆盖率测试,且我们在网上找的插件也大多都不再更新,剩下的也用不了(至少是没有找到用的办法),所以覆盖率检测暂时没法做。不过我们的单元测试应该基本是全覆盖。
五、UML图
六、算法
程序中涉及上一次地铁功能的算法来自石浩然同学,他的算法核心是只考虑换乘站,这样就只有四十多个点,然后做各种Dijkstra或者BFS效率就都很高,至于剩下的再进行处理就好。
程序实现了第一次中的-b、-c和-a功能,其中-a功能在UI中运行的同时,前台还可以完成-b和-c功能的查询。这里是运用了多线程处理。
程序UI我们是做了两次,第一次是用Winform做的,由于我们都是第一次写UI,界面做的比较简陋。功能基本完成后,又用WPF重新做了一次(这里石浩然同学是主力),比之前Winform漂亮很多。这里附上几张截图。
结对项目-地铁出行路线规划程序(续)