|
锁定老帖子 主题：尽量少用接口行不行
精华帖 (4) :: 良好帖 (18) :: 新手帖 (0) :: 隐藏帖 (9)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2012-02-03
flashing 写道 lz真可怜被投了9个隐藏。
这个话题说起来看似挺复杂其实很简单，任何东西都是为了生产力而来的，接口影响了生产力那还要这玩意干嘛。。。 至于什么时候需要，jdbc是个典型案例，jpa当然也算，要是这个理解不了一个单纯的web项目里面dao就写一堆接口那纯粹是古代日本人写法，要是没估计错项目里面可能还有一堆堆的什么po bo vo dto xo的。 接口最早的时候很多也为拦截而考虑，那时候大概大家只知道动态代理；现在能实现这个的库满天飞了都，何苦呢。。。 重构快键背的不熟时的确很影响生产力 |
| 返回顶楼 | |
|
发表时间：2012-02-04
接口就是一个黑盒子，对于需要保密源代码的来说，他就是一个屡试不爽的，主要是用于扩展性，但是lz这种情况就本末倒置了
|
| 返回顶楼 | |
|
发表时间：2012-02-04
阳光晒晒 写道 flashing 写道 lz真可怜被投了9个隐藏。
这个话题说起来看似挺复杂其实很简单，任何东西都是为了生产力而来的，接口影响了生产力那还要这玩意干嘛。。。 至于什么时候需要，jdbc是个典型案例，jpa当然也算，要是这个理解不了一个单纯的web项目里面dao就写一堆接口那纯粹是古代日本人写法，要是没估计错项目里面可能还有一堆堆的什么po bo vo dto xo的。 接口最早的时候很多也为拦截而考虑，那时候大概大家只知道动态代理；现在能实现这个的库满天飞了都，何苦呢。。。 重构快键背的不熟时的确很影响生产力 这个和重构快捷键有什么关系，是说直接从inerterface定义跳转到实现？ |
| 返回顶楼 | |
|
发表时间：2012-02-09
接口提供了可扩展性，但增加了维护的难度，相对的难于读懂，隐藏了实现过程。
|
| 返回顶楼 | |
|
发表时间：2012-02-10
ssooss 写道 接口提供了可扩展性，但增加了维护的难度，相对的难于读懂，隐藏了实现过程。
每一个东西都有最适合的场合，这样简单的说是不合理的。 |
| 返回顶楼 | |
|
发表时间：2012-02-13
kanme818 写道 你可真能写。。。我的想法和你一样，不能简单的用JDK或其他框架的设计思路去对比业务系统，从而评论接口哪里好哪里不好。 框架类项目和业务类项目最大的区别就是需求由谁主导。你写框架，需求和实现很大一部分是由你决定的，所以目标明确，需求稳定，可以抽象出接口，但是业务系统不一样，很多时候需求都在变，叫别人如何能抽象出接口，甚至于可以说，根本没接口，因为需要实现的目标都在变。 我是主张牵涉到业务逻辑的地方，抽象复用这些东西都需要更加谨慎，因为听的最多的就是客户说先按这个做，第二天又说这个需要改改。你抽象了一个看似共通的业务流程，可能第二天就被拆成两个完全不同的逻辑了，这种情况司空见惯了。 +1 业务系统，我个人感觉多采用些“敏捷”的思路，一开始就做接口契约，后面会发现被改的面目全非。 先实现着，后面看看重构时候要不要提炼出接口。 |
| 返回顶楼 | |
|
发表时间：2012-02-14
有些业务系统确实不需要使用太多的接口，但是使用接口开发可以培养良好的系统框架概念，能更深入理解系统的组成。
其实接口就是一种思想，是你要表达的思想，你期望系统能提供什么样的功能。可能你并不关心它到底怎样去实现，只要你的思想能很好的满足某一类业务的需求，那么你的思想就有可能成为标准。 J2EE的框架都是只提供接口不提供实现，大家最熟悉的就是servlet框架，你可以使用tomcat实现的servlet容器，可以使用resin实现的。 |
| 返回顶楼 | |
|
发表时间：2012-02-14
关键是，楼主项目的开发还不够模块化。 如果你用不同的人开发不同的模块，并且这两个模块又有相互调用的关系，那你不可能不用接口, 这是第一， 第二，如果你希望新人进来能够较快的上手工作，那你也不可能不用接口。
|
| 返回顶楼 | |
|
发表时间：2012-02-14
我认为不能太绝对，如果你实践过确实接口如上述那么多有点，你肯定、赞美这样面向接口的设计不错。
但我遇到的很多所谓的oo开发，过度需求，滥用接口，过度依赖容器，永远只有一个实现而且一成不变的例子很多。 设计只要适用就好，代码质量高不一定严格和那些书上的1、2、3、4一样 |
| 返回顶楼 | |
