今天听到一个观点,有点不知所错

尚浩宇 发布于 2016/09/08 16:05
阅读 3K+
收藏 2

        参加一个会议,有位说到:

        "接口写起来很麻烦,如果不是至少拥有两套实现就没有任何意义,项目中除非必要,不要写接口!凡是写接口的都是那些只会看代码不会写代码的专家。"

        如果这话出自一个初级中级程序员中,还可以理解是年少无知,但是这话出自公司聘请的资深程序员嘴中,我就有点不知所措了。

        现在提倡面向接口编程,设计模式中也大都依赖接口,他为什么那么说?

        由此,引发我如下的思考:

        1、java 开闭原则没了接口还要怎么实现更方便?

        2、是不是面向接口的代理不需要了?

        3、没了接口代码开发真的很快吗?

        4、类似dubbo的rpc框架如何使用?

        ……

        我找不到不需要接口的理由,仅仅只是增加代码量这个理由没有任何说服性,请教一下诸位,如果有和他观点一致的解答一下我以上的疑问。

加载中
3
魔力猫
魔力猫

第一,接口是为了解耦,如果不需要解耦,那么确实不用写。

第二,你可以不写,但是必须承担后期拆接口的成本。不能不负责光放炮。

第三,一切供外部调用的API,必须接口,不然就是犯罪。

很多所谓的资深其实是尸位素餐。年头长不等于真的有本事。到处都是接口固然不对,但是到处都没接口,其实还不如到处都是。

尚浩宇
尚浩宇
总结到位,兄弟同道中人
1
在下赵日天
在下赵日天
反正我认同。人家都说了如果不是至少拥有两套实现就没有任何意义,项目中除非必要,不要写接口,不要想着去写完美的代码,世界上没有完美的代码。
尚浩宇
尚浩宇
这个话题果然是中性的,公说公有理婆说婆有理
1
修改登录密码
修改登录密码
我怎么觉得这句话这么不通顺呢。。。
1
原版什锦八宝饭
原版什锦八宝饭
这句话的核心是谁来确定肯定不需要两套实现。。能不能确定只需要一套实现。
1
同城陌路人
同城陌路人
楼主别着急,事实还真是这样,新手为求进步大都会过度设计。这个现象好理解,若从程序员的角度看,写好代码有助于程序员自身的提高,但若是从架构或者做事的角度看,只要在大局的容忍范围内,代码好坏真是没那么重要,能实现产品需求即可,考虑的是一个投入产出比问题(这个问题通常是由架构师来解决)。
同城陌路人
同城陌路人
回复 @尚浩宇 : 我觉得,你说出了一条标准的程序发展道路,但是没提到这条路的后半段,年纪上去之后,考虑问题的角度会发生变化,大部分人会更关注工作的成果,而专研技术反而变成业余娱乐
尚浩宇
尚浩宇
有点毁三观的感觉,从接触java到现在总是有人强调解耦,强调设计,习惯了之后再遇到这种论点就尴尬了
1
AlanShi
AlanShi
他是个说实话的人
1
悠悠然然
悠悠然然
呵呵,这个问题要这么看:
加个接口的成本和不加接口的成本。

实际上就现在用Spring的环境下,加个接口的成本几乎可以忽略不计的。

而如果没有接口,以后如果需要加个接口的话,那成本,海了去了。比如:原来用hibernate,然后你没有用接口,确实也没有什么问题,结果Hibernate出现一个比较大的BUG,结果说要换成ibatis,结果你都懂的。

还有一个比较大的问题是,用接口,可以隔离实现,而如果不用接口的话,鬼知道有多少实现层的对象被外面直接依赖了,如果这一天出现的时候,呼天抢地也没有什么用了。

所以,早用接口,即使没有多种实现,实际上带来的成本也可以忽略不计,还可以避免各种不恰当的依赖。而不用接口,用墨菲定律说,如果会变坏那就一定会变坏。如果可能把实现细节的类被外面依赖,那就一定会被依赖。

所以,我的结论很明确,有明确的接口来定义你的行为,为隔离你的实现总是好的,即使会增加一点成本,也完全可以忽略不计。

而那些说如果那啥的情况下就不用接口的同学,你可以看看他的代码,然后就明白了。

所以,有些专家实际上是砖家的,而砖家说的话往往不能一下子被人看透的,尤其是对一些层次不太高的同学。否则他怎么忽悠?

魔力猫
魔力猫
没有接口,要加接口。成本大小要看原本的设计水平。而基本上,设计水平都要往坏了想。而且还有很多就是加了接口也搞得紧耦合的糟糕家伙和取名无能的家伙。比如写个Dao接口,却把实现都写上面了,来个IHierateDao的接口,然后是HibernateDaoImpl的实现,这种属于脑残没救的。
尚浩宇
尚浩宇
和我想法一致
0
MockMan
MockMan
就业务层面的代码来说,这点确实让我困惑,感觉大多数是无用功
尚浩宇
尚浩宇
回复 @烟头 : 肯定需要,我是觉得接口利大于弊
烟头
烟头
回复 @尚浩宇 : spring的拦截不需要有接口啊
尚浩宇
尚浩宇
但如果从设计角度,后续扩展和维护呢?比如现在要统一记录日志,但只记录操作的日志不记录查询类的日志,如果有接口,我可以做aop拦截,很容易实现,但是如果没有,要么继承,要么手动在原代码里加日志。后期维护成本太大了,毕竟在公司并不是总是在开发,维护也占了工作的一部分。
0
tonysb
tonysb

如果不是至少拥有两套实现就没有任何意义,项目中除非必要,不要写接口

为什么我觉得他说的挺对的,如果项目中只有一种实现的话,确实没必要去写接口

尚浩宇
尚浩宇
公司里新项目并不是那么多,大多都是在做二次开发,这个时候这句话就有矛盾了,从开发角度说,开发效率快,减少代码量,确实很好。但从维护和二次开发角度上来说,确实也会带来不少的麻烦。
0
雨翔河
雨翔河

一个小项目,就输出一个hello world,我是不写接口的,直接psvm然后sout。

qycms_cn
qycms_cn
回复 @尚浩宇 : 在新项目初期,没有人敢保证能成功,90%以上会很快给迭代掉。搞接口开发,测试部置,效率上明显处于劣势。不如直接编码。
wj2699
wj2699
IDEA君
尚浩宇
尚浩宇
回复 @雨翔河 : 好吧
雨翔河
雨翔河
回复 @尚浩宇 : 然而就是一个hello world。
尚浩宇
尚浩宇
我觉的无论项目大小,都要考虑后期维护的问题,尤其后续二次开发的问题,我的原则就是最小或尽量不动原代码一句话,因为那不是我写的,我不知道他是要干嘛,可能我动了,引发了一系列连锁效应而产生新的问题,而接口很大程度上就能帮我做到这些
返回顶部
顶部