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