|
锁定老帖子 主题：尽量少用接口行不行
精华帖 (4) :: 良好帖 (18) :: 新手帖 (0) :: 隐藏帖 (9)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2012-02-02
KimHo 写道 接口是个带有清晰操作语义的事物，能让分析设计人员对现实世界的概念做更好的抽象
从分析设计来看，接口是不可少的，还有抽象类的设计。 针对这个回复一下，前提就是需求分析都很明确，而事实是需求多变，理论和现实的差异。 而且接口带了函数的参数，这个就比较讨厌了。因为参数表示了具体的需求，当然我知道参数可以是对象。 所以可能要看项目大小，小的话少用或不用，大的话用。 |
| 返回顶楼 | |
|
发表时间：2012-02-02
没用的、冗余的抽象只会给代码带来负担。
|
| 返回顶楼 | |
|
发表时间：2012-02-02
xieye 写道 KimHo 写道 接口是个带有清晰操作语义的事物，能让分析设计人员对现实世界的概念做更好的抽象
从分析设计来看，接口是不可少的，还有抽象类的设计。 针对这个回复一下，前提就是需求分析都很明确，而事实是需求多变，理论和现实的差异。 而且接口带了函数的参数，这个就比较讨厌了。因为参数表示了具体的需求，当然我知道参数可以是对象。 所以可能要看项目大小，小的话少用或不用，大的话用。 就没见过需求明确的客户~~~ 
|
| 返回顶楼 | |
|
发表时间：2012-02-03
kanme818 写道 xieye 写道 KimHo 写道 接口是个带有清晰操作语义的事物，能让分析设计人员对现实世界的概念做更好的抽象
从分析设计来看，接口是不可少的，还有抽象类的设计。 针对这个回复一下，前提就是需求分析都很明确，而事实是需求多变，理论和现实的差异。 而且接口带了函数的参数，这个就比较讨厌了。因为参数表示了具体的需求，当然我知道参数可以是对象。 所以可能要看项目大小，小的话少用或不用，大的话用。 就没见过需求明确的客户~~~ 因为需求不明确和需求经常变更，所以代码重构是必须的，而接口很多在代码重构时确定的。 抽象的目的是为了适应以后的多变和不确定性而不是为抽象而抽象的，也就说抽象的目的其实是为了解决需求的不确定性，简单说就是以不变的应万变。 但是项目已开始时如果对项目没有全面的把握还是不要抽象的好，因为不知道那些是不变的，那些是可变的，以及可变中那些是不变的。但是在代码重构中是可以找到规律的，如果项目经验非常丰富也是可以很快找到的。 |
| 返回顶楼 | |
|
发表时间：2012-02-03
magic_seek 写道 kanme818 写道 xieye 写道 KimHo 写道 接口是个带有清晰操作语义的事物，能让分析设计人员对现实世界的概念做更好的抽象
从分析设计来看，接口是不可少的，还有抽象类的设计。 针对这个回复一下，前提就是需求分析都很明确，而事实是需求多变，理论和现实的差异。 而且接口带了函数的参数，这个就比较讨厌了。因为参数表示了具体的需求，当然我知道参数可以是对象。 所以可能要看项目大小，小的话少用或不用，大的话用。 就没见过需求明确的客户~~~ 因为需求不明确和需求经常变更，所以代码重构是必须的，而接口很多在代码重构时确定的。 抽象的目的是为了适应以后的多变和不确定性而不是为抽象而抽象的，也就说抽象的目的其实是为了解决需求的不确定性，简单说就是以不变的应万变。 但是项目已开始时如果对项目没有全面的把握还是不要抽象的好，因为不知道那些是不变的，那些是可变的，以及可变中那些是不变的。但是在代码重构中是可以找到规律的，如果项目经验非常丰富也是可以很快找到的。 我觉得很多技术人员都有少许的强迫症，他们总是会担心各种各样的变化，从我们的教科书到各种论坛，每个人都在谈论需求变化和应对方式。放佛全世界都会变~~~~ |
| 返回顶楼 | |
|
发表时间：2012-02-03
fireflyc 写道 magic_seek 写道 kanme818 写道 xieye 写道 KimHo 写道 接口是个带有清晰操作语义的事物，能让分析设计人员对现实世界的概念做更好的抽象
从分析设计来看，接口是不可少的，还有抽象类的设计。 针对这个回复一下，前提就是需求分析都很明确，而事实是需求多变，理论和现实的差异。 而且接口带了函数的参数，这个就比较讨厌了。因为参数表示了具体的需求，当然我知道参数可以是对象。 所以可能要看项目大小，小的话少用或不用，大的话用。 就没见过需求明确的客户~~~ 因为需求不明确和需求经常变更，所以代码重构是必须的，而接口很多在代码重构时确定的。 抽象的目的是为了适应以后的多变和不确定性而不是为抽象而抽象的，也就说抽象的目的其实是为了解决需求的不确定性，简单说就是以不变的应万变。 但是项目已开始时如果对项目没有全面的把握还是不要抽象的好，因为不知道那些是不变的，那些是可变的，以及可变中那些是不变的。但是在代码重构中是可以找到规律的，如果项目经验非常丰富也是可以很快找到的。 我觉得很多技术人员都有少许的强迫症，他们总是会担心各种各样的变化，从我们的教科书到各种论坛，每个人都在谈论需求变化和应对方式。放佛全世界都会变~~~~ 的确有这种情况，但是担心变化是没有必要的。另外变化总是避免不了的，而变化中的不变就是接口啦。 |
| 返回顶楼 | |
|
发表时间：2012-02-03
抽象类其实是个泛型设计，目的就是为了后期能通过抽象类的特化来实现系统功能的扩展。
举个例子吧： 学校的课程管理系统，刚开始，系统功能要求比较简单，需要管理学生参与课程的具体情况，于是有了如下的设计：类Course（课程）与抽象类Person（人）下的某个子类Student（学生，也就是抽象类Person的特化）建立了关联，关联关系为attendCourse（参与课程） 但业务功能总会越来越多，随着业务发展，现在需要扩展下系统功能，需要管理教师教授课程的具体情况，于是又有了如下设计：来个教师类Teacher（教师，依然是抽象类Person的特化），Teacher和Course也建立了关联，关联关系为teachCourse（教授课程） 如此继续发展下去，一个越来越复杂，越来越强大的系统就此出现…… |
| 返回顶楼 | |
|
发表时间：2012-02-03
最后修改：2012-02-03
elf8848 写道 cataclyzh 写道 碰到一个项目,许多只有一个实例的类也定义了接口,而且这些类还经常要添加方法.结果偷懒的人就在使用到接口的地方直接一个强制装换.
比如函数中传递了IObjectManager接口的,这个接口里面原来只有一个search(String id)方法,后来实现类经常添加方法,修改的人每次改了实现后还要在添加接口定义.结果有些地方的调用就出现了这样的代码: ((IObjectManagerImpl)IObjectManager).search(obj) 问题是这样的代码还运行的挺好的,历经测试,一直延续到最新的版本. 写这样的调用确实不好.但也算事出有因.因为不当的接口使用增加了编码的工作量. 想了想自己使用接口的地方不算多,主要是: 1. 一个接口有多个实现.最常见的是定义事件监听. 2. 需要交给Spring管理的类(一般是DAO层和service层的类). 其他的地方一般先不考虑定义接口.以后有需要了,再加. 思考的好啊! 这种思考是实践之后做出的思考,比其它人只看书本人云亦云未经实践总结就说出来的一套套理论好多了. 写与不写接口,这种大家每天都在做的平常平常平常平常事儿,是很难以讨论难以达成共识的,因为人人天天都在做这件事儿,人人都有自己的观点与看法,人人都认为自己的做法是正确的才去行动,没有人认为自己做的是不对的. 平凡中见真谛,这种思考不应该被投隐藏贴.应积极讨论,百家争鸣. 前面有人提到了JDBC的接口,JDBC的接口用的好啊, 太好了.没人说不好. 因为没有接口JDBC就不能活. SUN公司定义JDBC规范时若不使用接口, 真没有别的方法. 比如说SUN公司1990年制定的JDBC规范(不知具体哪年), 2000年时问世了一个新数据库A公司,实现了JDBC规范,之后大家就可以使用A公司的数据库了. 所有程序员惊呼----接口万岁,并发誓以后我也充分运用接口. 比如说Apache 2008年开发了Struts2(不知具体哪年),C人2010年开始使用Struts2,并发现默认配置不能满足业务,所以他针对Struts2的接口做了扩展. 所有程序员惊呼----接口万岁,并发誓以后我也充分运用接口. 请注意以上两个事儿共有的3个特点: 1.一个接口有多个实现类(必需是多个,不然说服力不够) 2.有两个角色,SUN公司--A公司,Struts2--C人 3.有时间差,1990年--2000年,2008年--2010年 以上三点太重要了,请先记住. 转眼间到了2012年 ,cataclyzh(楼主)等人 开始开发自己公司的项目,这是一个以增删改查为主的项目,是最帖近用户的项目,并非JDBC,Struts2一类给程序使用的项目. 并定下目标,要写最好的程序:有良好的扩展性,有高质量的代码,有快速跟进用户需求变化的能力,等等..... 项目开发中.... 一个月,两个月...八个月... cataclyzh(楼主)等人遇到的第一难题是:用户需求一变再变 cataclyzh(楼主)等人遇到的第二难题是:交付日期一推再推 经理的脸色越来越难看, 大家开始加班,加班,加班 .修改,修改,修改. cataclyzh(楼主)等人 开始抱怨:实现类经常添加方法和修改,修改的人每次向实现类加了新方法后,还要在接口加添加同样的方法名,甚至项目组里有人偷懒写了楼主说的强制转换代码. 请大家注意这个顺序,是先改实现类,再把代码COPY到接口当中修改接口.完全不是大家预先设想的先定义接口,后写实现类,现在的情形与书中例子说的接口的好处,与其它人的说的接口的好处截然不同,到目前为止cataclyzh(楼主)等人没有体会接口的半点好处.就陷入了深深的思考/深深的思考/深深的思考. 其实这种"快速跟进用户需求变化"的项目,接口是很难抽象出来的(主要是增删改查的业务部分). 当cataclyzh(楼主)等人困惑时,来ITEYE发贴求问,还被投了隐藏贴.  ,在这里我投你一个精华
还记得前面提到了 "共有的3个特点" 吗? 我们来分析一下,cataclyzh(楼主)所在的项目, 拥有几个? 1.一个接口有多个实现类-- 没有,cataclyzh(楼主)的接口只有一个实现类. 2.有两个角色--没有,永远是cataclyzh(楼主)这一个项目组的三五个人.同一个项目组算一个角色. 3.有时间差--或许有但不明显,基本都是当年或两一二年的项目. 经理的脸色越来越难看,所以眼前的情形是要应付的, 但也要有长远的目光.接口带来的好处是有目共睹的.cataclyzh(楼主)如果想收获接口带来的好处, 还需要先顶过目前的难关,再未来扩展时或许会收获到. 这还是一个"或许",因为但愿你公司的这个最贴近用户的产品还有扩展的机会.jdbc扩展的机会是无限大的不会消失,但你的产品.... 这时候"敏捷"更重要. 最后再重复一次前面说过的话:写与不写接口,这种大家每天都在做的平常平常平常平常事儿,是很难以讨论难以达成共识的,因为人人天天都在做这件事儿,人人都有自己的观点与看法,人人都认为自己的做法是正确的才去行动,没有人认为自己做的是不对的. 真厉害，起码是自己的想法，不想前面那堆人，部分场景地抄了一些书上说的接口的好处赚回帖分。 其实刚开始入门时哥也是对着书上抄的，任何service、dao类都写一个接口。但是写了这么多年，发现它们在单元测试写mock时有用外（非必要，无接口可以直接继承要mock的类），基本是用来摆设的，在变动时还常常苦恼，为什么要多些一个接口呢？现在作为一只老鸟，对于service和dao，如果不需要两套近似的实现（比如各种支付实现），已经不写这个多余得蛋疼的东西了。 只是，现在新公司的php框架，粗糙地仿了struct，没个业务实现竟然要强制写接口，坑爹啊，一种弱类型语言，用factory创建了一个实例后连编辑器的自动完成都认不出来是什么类型的，即使偷懒只写实现不写接口也不会有运行错误，这才叫完完全全的摆设啊，吐槽完毕。 |
| 返回顶楼 | |
|
发表时间：2012-02-03
lz真可怜被投了9个隐藏。
这个话题说起来看似挺复杂其实很简单，任何东西都是为了生产力而来的，接口影响了生产力那还要这玩意干嘛。。。 至于什么时候需要，jdbc是个典型案例，jpa当然也算，要是这个理解不了一个单纯的web项目里面dao就写一堆接口那纯粹是古代日本人写法，要是没估计错项目里面可能还有一堆堆的什么po bo vo dto xo的。 接口最早的时候很多也为拦截而考虑，那时候大概大家只知道动态代理；现在能实现这个的库满天飞了都，何苦呢。。。 |
| 返回顶楼 | |
|
发表时间：2012-02-03
gtssgtss 写道 去问问c++的人纯虚类怎么用，就知道了接口该怎么用了
那还得明白动态库静态库虚函数表直接开课了 更确切的说是明白dll/so这种动态库的作用是什么 |
| 返回顶楼 | |
