|
精华帖 (0) :: 良好帖 (23) :: 新手帖 (6) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-10-07
记得当初大家盛赞Spring的功德时，经常提的一条是“极大降低了面向借口编程的成本”，我猜测就是这句话导致接口泛滥现象
其实没有接口一样DI，需要接口的唯一理由应该就是“有多个实现策略” 或许Mock测试也算一个理由，但那也是以前的事了，现在easymock可以mock具体类了 |
| 返回顶楼 | |
|
发表时间：2008-10-07
lonelybug 写道 但是，中国人有句老话，叫做杞人忧天，很多的时候，你有没有内心问自己，这个系统，我设计的，如果老板要改动，我可以在很短的时间内做到改变么？ 你这成语用的，真是……南辕北辙，我反复推敲半天才看出来，原来楼主是在提倡用接口！ 
|
| 返回顶楼 | |
|
发表时间：2008-10-07
jsp+javabean开发飞快啊~
出问题就爽了 |
| 返回顶楼 | |
|
发表时间：2008-10-07
jacky2007 写道 很多时候定义接口的跟写实现类的并非同一人....
虽然很喜欢Interface，不过.... 说实话，非常厌恶这种开发方式。 |
| 返回顶楼 | |
|
发表时间：2008-10-07
jansel 写道 不管是SSH还是别的IOC框架，这些框架大家只要按照一定个约束去Coding就可以了。
我是深受上百万行代码难以维护的害了，那些代码里面基本上充斥的都是静态方法，类之间的依赖大家都没有办法想象。 所以才会去用框架去解决这些问题，对于自己的产品来说，维护我现在放在第一位了。开发效率低不要紧（纯粹的JSP+JAVABean开发是很快，但是维护也难，关键是不容易建立一套约束的东东） 如果从维护角度考虑，我宁愿去分层，层与层直接会用接口实现。 像我现在做的，dao-manager-service-action搞了这么多层，到头来业务逻辑还有写到存储过程里的。维护起来那叫一个要命，还要在这基础上开发新版本。我已经有闪人的打算了。 |
| 返回顶楼 | |
|
发表时间：2008-10-07
跟这位axeon大神无关，我想说的是，接口这玩意本身也是有依赖性的，两个一摸一样的的接口只要声明的名称不同认定的就是不同的接口，这样两个包相互不需要管理对方存在特性就能彼此合作的松耦合还是做不到，接口自身仍旧还是包的一部分。
而且现在反射好用了之后，类的桎梏基本上也可以打破了，两个完全没有接口和类继承体系关系的对象可以靠（可配置的）属性（和过程？）名称来相互通信，伪ducktype勉强可以成立，世界已经大同了，接口先辈您就微笑着看着俺们建设社会主义吧…… |
| 返回顶楼 | |
|
发表时间：2008-10-08
我感觉用接口，利于代码重构，也易于维护。:-)
|
| 返回顶楼 | |
|
发表时间：2008-10-08
照LZ意思,PC各大厂商也可以全把板卡焊在一起,互相不兼容,还要什么PCI,IDE接口干嘛?
|
| 返回顶楼 | |
|
发表时间：2008-10-08
WhisperXD 写道 接口其实更多的用于抽象和规约
同意
比如协同工作期间，订立接口有助于双方相互间调用的规范。 同时也有助于自顶向下的思考。 在内部实现中，接口实现多态也有不少用处，不过也不是每一个地方都要用。 实现好了，需要的时候简单重构一下，就能获得接口的相关特性。 |
| 返回顶楼 | |
|
发表时间：2008-10-08
这个问题。。
其实现在的开发中很多业务开发对于接口并不是十分的了解，只是项目开始时规定了怎么去用比如SS:AC,FB,IA,接口实现,业务层。这是开发前规定好的，你不这么做代码评审时会被KO的。 一些业务上的代码运用接口其实没什么必要。 |
| 返回顶楼 | |
