Pair project(刘昊岩11061156 黄明源11061186)

Pair project members:刘昊岩11061156,黄明源11061186

  两周时间,工程下午刚刚结束,现做一些总结。

  在现有工程基础上修改schedule 包下方法,主要思想是,也就是关键所在:电梯停的时候判断往哪里走,走的过程中顺路带人,电梯里有人先满足里面人的需求(就是直到把里面人全部送达目的楼层),然后回到电梯停的状态。主要代码框架如下(列个框架应该没问题吧):

  判断电梯当前是否运行,如果运行,执行PickInTheWay()方法,否则执行RunNewReq()方法。前者作用是在电梯运行中,把路过楼层与电梯当前运行方向有相同需求的乘客拉上来(语言表达能力有限啊= =),后者是电梯不动时候搜索新的乘客请求,这里又分为有乘客和没有乘客情况。有乘客时候,先满足内部需求,电梯运行方向与内部需求方向相同,没有乘客时候,进行一个判断(难以表达清楚,详见代码= =)

  单元测试如下:

 


 

  现在说下结对编程的感受,这是第一次做结队编程,感觉十分新鲜,是一种很好的工作方式,不过我们认为有利有弊。

  首先说缺点:

  1. 不能称之为缺点,只是针对我们目前情况,觉得不是十分妥当,我们觉得结队编程针对的应该是大牛级别,或者有一定编程能力的人。我们作为初学者,现在只能感受结对编程的魅力,却无法完美发挥它的优势。
  2. 有时候思路不同,难分上下又难以统一。

  然后说优点:

  1. 合理分配成员任务,能使工作更高效。
  2. 有助于成员间互相帮助,互相学习,提高代码水平。
  3. 成员间互相审阅代码,有助于提高代码质量,减少bug发生。也能使成员间互相督促,相比较单独作战,更能让人认真起来。
  4. 结对编程避免了“我的代码”还是“他的代码”的问题,使得代码的责任不属于某个人,而是属于两个人,进而属于整个团队,这样能够帮助建立集体拥有代码的意识,在一定程度上避免了个人英雄主义。 

  对于本次Pair Project,我和partner配合比较成功,

  我对partner的评价:

      至于必须写的一个缺点嘛……明源你下次写代码时多写点注释,我改的时候也方便些哈。。

  partner对我的评价:

      昊岩是一个超级认真的大学霸,做事情一丝不苟,为了研究算法,特意跑到新主教去细致调查了一下实际电梯的运行方式!然后为了画好UML图一步一步调试,很辛苦的自习到很晚!超级棒的partner!而且很能抠细节,往往能注意到别人发现不了的问题,对于程序修改帮助十分大!

      至于缺点,暂时还没想到~,不过他非让写,即使工程量大也不要这么学霸,给人压力好大。


 

    Design by contract :

  契约式设计(DbC),是一种设计计算机软件的方法。这种方法要求软件设计者为软件组件定义正式的,精确的并且可验证的接口,这样,为传统的抽象数据类型又增加了先验条件、后验条件和不变式。这种方法的名字里用到的“契约”或者说“契约”是一种比喻,因为它和商业契约的情况有点类似。

  DbC的核心思想是对软件系统中的元素之间相互合作以及“责任”与“义务”的比喻。这种比喻从商业活动中“客户”与“供应商”达成“契约”而得来。

  DbC的关键:

一 前置条件(precondiction): 为了调用函数,必须为真的条件,在其违反时,函数决不调用,传递好数据是调用者的责任。 二 后置条件 (postcondion): 函数保证能做到的事情,函数完成时的状态,函数有这一事实表示它会结束,不会无休止的循环 三 类不变项(class invariant): 从调用者的角度来看,该条件总是为真,在函数的内部处理过程中,不变项可以为变,但在函数结束后,控制返回调用者时,不变项必须为真。         通过对 http://www.cnblogs.com/riccc/archive/2007/11/28/design-by-contract-dbc.html博客的仔细阅读,发现他对于契约式设计有一个我觉得十分明白的比喻,现引用过来加以学习理解。契约式设计就是要求提供一套机制,在客户程序与提供者之间明确的声明双方的职责与权利,即契约,并能够对这些契约进行验证。 Building bug-free O-O software: An introduction to Design by Contract ?中的例子:向一个有限容量的字典(使用字符串键值存取各个元素)中插入某个元素,契约如下:

  义务 权利
客户程序  (必须保证前置条件) 
 确保字典没有满,键值是非空字符串
(从后置条件获益) 
 更新字典使新的元素出现在字典中,并跟给定的键关联起来
提供者 (必需保证后置条件) 
 将给定元素放入字典中,并跟给定的键关联起来
 (可以假定前置条件成立) 
 如果字典满了,或者键值为空字符串,可以不处理 

    使用Eiffel语法描述:假如这是一个范型类DICTIONARY[ELEMENT]的put方法   

     这个例子中,很好的体现了客户和提供者之间的契约关系,前置条件和后置条件清晰易懂。

  本次Pair Project 中,由于关系复杂,这种契约关系不是十分清晰易懂,不过还是处处可见,对Elevator、Passengers的操作,对EnterElevator,LeaveElevato,ReqStopAt等等方法的运用 ,更是集中体现了DbC的特点,用户与提供者错综复杂的关系在前置条件和后置条件的制约下工作得井井有条。


 information hiding , interface design and loose coupling:

  information  hiding:在面向对象方法中,信息隐藏通过对象的封装性来实现。把希望隐藏的变量设置成private类型,对外公开接口,外界只有读权限。  

  loose coupling:松散耦合是指使用另一个组件提供服务的一个组件对前者的依赖性不强:它是语言独立的、平台独立的事务。

相关资源:岩质边坡稳定分析软件-其它文档类资源-CSDN文库

声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!

上一篇 2013年9月5日
下一篇 2013年9月6日

相关推荐