|
锁定老帖子 主题：对于接口越来越迷茫
精华帖 (0) :: 良好帖 (6) :: 新手帖 (4) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2012-02-24
最后修改：2012-02-24
iaimstar 写道 youarestupid 写道 什么乱七八糟的鸟儿逻辑，不懂不要装懂！ 你不要不懂装懂,虚心点 其他地方我真的不懂，但是在接口应用上，我自我认为还是有点“真懂”，最起码我没有“对接口越来越迷茫”。 我对接口的应用很清晰： 我的团队成员所接触到的所有架构层代码，全部是我暴露给他们的接口API； 而团队成员所做的，仅仅是调用这些接口的方法就可以。 至于接口是哪个实现类来实现的功能，这个他们都不用去关心，因为接口实现类的注入也是架构师来完成的，我的团队成员工作量非常小，根本不用关心“什么时候用接口、什么时候不用接口”！ 至于那些什么Service、Controller之类的，根本算不上接口的应用范围，直接继承一个父类即可。 真正的接口应用，是类似如下这些场景： 1、通用DAO接口； 2、收发Email接口； 3、数据导入、导出接口； 4、Web Service交互封装接口； 5、动态表数据保存逻辑封装接口； 6、JMS封装接口； 7、服务器端推送封装接口； 8、…… 等等。 这些才能算得上是应用接口的地方，你给使用者一个接口，使用者不用关心这些功能用哪个类来实现的，直接调用接口的方法就会映射到合适的实现类的真实方法上去； 至于那些Service、Controller之类的玩意儿，直接继承一个通用父类就OK了，根本算不上接口的应用范畴。 如果你硬要说一个Service有多种业务实现，那也可以用一用接口，但是这个Service接口的提炼，应该有项目技术负责人统一定义，不能放任流水线程序员自己发挥，否则维护后果很严重。 |
| 返回顶楼 | |
|
发表时间：2012-02-24
最后修改：2012-02-24
接口真的是 程序员的事
和架构师没关系 我们团队的架构师 只干两个事,评估 需求的技术可行性和环境可行性 如何提高团队的作战实力 youarestupid 写道 在我们团队，普通组员一个接口都不用写，他们写了我也会让他们删除，因为接口是架构师的任务，他们没有能力定义一个具有约束力的接口。 ]
你们团队有每天都有新的需求要评估,开发,每天都有多个功能上线的运行的情况 你让架构做所有接口,你们架构太糟践了,干苦力干的活 |
| 返回顶楼 | |
|
发表时间：2012-02-24
最后修改：2012-02-24
iaimstar 写道 接口真的是 程序员的事
和架构师没关系 我们团队的架构师 只干两个事,评估 需求的技术可行性和环境可行性 如何提高团队的作战实力 youarestupid 写道 在我们团队，普通组员一个接口都不用写，他们写了我也会让他们删除，因为接口是架构师的任务，他们没有能力定义一个具有约束力的接口。
你们团队有每天都有新的需求要评估,开发,每天都有多个功能上线的运行的情况 你让架构做所有接口,你们架构太糟践了,干苦力干的活 这是软件架构师的任务么？ 需求评估、可行性评估？ 这也是软件架构师的任务？这是项目经理的任务吧？ 项目经理负责可行性评估、需求分析，如果项目需求上搞砸了，项目经理有责任，跟软件架构师一点关系都没有，软件架构师只负责技术层面的设计，不负责业务需求的分析。 |
| 返回顶楼 | |
|
发表时间：2012-02-24
iaimstar 写道 接口真的是 程序员的事
和架构师没关系 我们团队的架构师 只干两个事,评估 需求的技术可行性和环境可行性 如何提高团队的作战实力 引用 在我们团队，普通组员一个接口都不用写，他们写了我也会让他们删除，因为接口是架构师的任务，他们没有能力定义一个具有约束力的接口。
你们团队有每天都有新的需求要评估,开发,每天都有多个功能上线的运行的情况 你让架构做所有接口,你们架构太糟践了,干苦力干的活 这是软件架构师的任务么？ 需求评估、可行性评估？ 这也是软件架构师的任务？ 当然是,项目的资源是架构师在控制的,架构师有权利直接 毙掉 不实际的需求 |
| 返回顶楼 | |
|
发表时间：2012-02-24
youarestupid 写道 iaimstar 写道 接口真的是 程序员的事
和架构师没关系 我们团队的架构师 只干两个事,评估 需求的技术可行性和环境可行性 如何提高团队的作战实力 youarestupid 写道 在我们团队，普通组员一个接口都不用写，他们写了我也会让他们删除，因为接口是架构师的任务，他们没有能力定义一个具有约束力的接口。
你们团队有每天都有新的需求要评估,开发,每天都有多个功能上线的运行的情况 你让架构做所有接口,你们架构太糟践了,干苦力干的活 这是软件架构师的任务么？ 需求评估、可行性评估？ 这也是软件架构师的任务？ 我们的架构师只写文档，分析需求，不涉及实现。。 你们的团队难道只有两种角色吗， 1 架构师 2 “流水线码农” |
| 返回顶楼 | |
|
发表时间：2012-02-24
youarestupid 写道 iaimstar 写道 接口真的是 程序员的事
和架构师没关系 我们团队的架构师 只干两个事,评估 需求的技术可行性和环境可行性 如何提高团队的作战实力 引用 在我们团队，普通组员一个接口都不用写，他们写了我也会让他们删除，因为接口是架构师的任务，他们没有能力定义一个具有约束力的接口。
你们团队有每天都有新的需求要评估,开发,每天都有多个功能上线的运行的情况 你让架构做所有接口,你们架构太糟践了,干苦力干的活 这是软件架构师的任务么？ 需求评估、可行性评估？ 这也是软件架构师的任务？ 当然是,项目的资源是架构师在控制的,架构师有权利直接 毙掉 不实际的需求 那你们公司的软件架构师起到了项目经理的作用了，应该要求加薪。 |
| 返回顶楼 | |
|
发表时间：2012-02-24
最后修改：2012-02-24
zouruixin 写道 youarestupid 写道 iaimstar 写道 接口真的是 程序员的事
和架构师没关系 我们团队的架构师 只干两个事,评估 需求的技术可行性和环境可行性 如何提高团队的作战实力 youarestupid 写道 在我们团队，普通组员一个接口都不用写，他们写了我也会让他们删除，因为接口是架构师的任务，他们没有能力定义一个具有约束力的接口。
你们团队有每天都有新的需求要评估,开发,每天都有多个功能上线的运行的情况 你让架构做所有接口,你们架构太糟践了,干苦力干的活 这是软件架构师的任务么？ 需求评估、可行性评估？ 这也是软件架构师的任务？ 我们的架构师只写文档，分析需求，不涉及实现。。 你们的团队难道只有两种角色吗， 1 架构师 2 “流水线码农” 我们公司确实是一个我这样的半吊子软件架构师 + 几个游手好闲的流水线程序员。 不过写文档、分析需求这些任务也不是软件架构师的任务范畴！ |
| 返回顶楼 | |
|
发表时间：2012-02-24
我还真没说接口无用，而是在讲被滥用了。前面第一个回复就是讲个该怎么用。
其实说白了这玩意明白了就是明白了，不明白就是在瞎搞。 你说的我觉得很对，简单就是美，码农就是码农，组件就是组件。 youarestupid 写道 flashing 写道 downpour 写道 在J2EE的应用程序中编写接口，与实际的业务场景有很大的关系。我这里有一个比较现实的例子可以描述一下。
我们在做一个美国项目的时候，有一段业务逻辑需要连接到美国的另外一个应用程序获得一个状态信息，这个远程调用非常慢，通常返回一个结果需要10分钟。比较恶心的一点是，这个状态信息是业务逻辑的关键信息，我们不得不根据不同返回情况来编写后续业务。 这时候接口的作用就体现出来了。因为这个Service Call一旦是一个接口，我们就可以使用其他的实现类来代替原本非常恶心的Remote Call的实现，从而使得我们能够从非常慢的一个远程调用中解脱出来。 所以，在典型的应用程序中，使用接口进行编程的核心作用是可以在适当的时机切换不同的实现方式从而是整个过程变得更为可控。 当然，另外一点，楼主也可以参考一下。楼主可以去浏览一下所有的设计模式，看看这些设计模式的应用是不是绝大多数都建立在接口的基础之上？所以接口的使用在很大程度上是最佳实践的一种集合体现。 之前的一些说法，有的相对比较靠谱，有的则毫无逻辑。希望楼主在参考时加以甄别。 这个说法很滑稽，用了接口就能解决一个remoting 10分钟？如果你仅仅是需要cache一下，那和接口也没有关系。典型的remoting架构里面，一个proxy模式是很正常的，所有底层的工作都应该在这个层面进行，过去的确什么模式都有，corba的代码生成，ejb的接口，至于各种ws*和rest的服务，说实话没有接口有个文档一样可以访问或者通过自描述来导入服务，强制的接口越来越没有必要。 换句话说接口是纯虚的，纯虚啊，这个虚字是重点啊，每次查实现的。。。 最后：所以，在典型的应用程序中，使用接口进行编程的核心作用是可以在适当的时机切换不同的实现方式从而是整个过程变得更为可控。 这句话就是在骗自己，99%的时候，这是不可能的。尤其是写个xxxdao然后写个xxxdaoimpl这种的，用了jdbc的指望以后换jpa、mybatis或者hibernate，写了xxxservice再写个xxxserviceimpl然后指望通过配置就直接暴露服务的，都是在玩自己。。。 另外代码量的增多其实让整个过程更不可控，java的程序员都太过渡设计了，考虑了太多没用的东西，举个例子，apache的httpclient3.1->4.x，最近再一比较python的urllib，全是眼泪啊。。。 首先，关于downpour说的“远程调用慢”，这个情景确实跟用不用接口没什么关系，如果一定要有点关系，那就是写一个远程调用的接口，开发阶段使用本地虚拟环境作为接口实现类，这样访问快，开发快；正式部署阶段，换上调用实际远程地址的接口实现类。 然后关于你说的接口无用论，我想说的是，接口用于不用，可以用两句话笼统地概括出来： 对于软件架构师：接口是大用特用，理论上软件架构师暴露给架构应用者的代码，应该全部是接口； 对于普通流水线码农：接口能不用就不用，因为你不够资格，也不需要，接口定义是架构师的工作，码农没有能力定义接口、约束实现。 ================================================================================= 接口这任务，从流水线码农身上摘掉以后，码农自己也轻松了很多。 在我们团队，普通组员一个接口都不用写，他们写了我也会让他们删除，因为接口是架构师的任务，他们没有能力定义一个具有约束力的接口。 我们的团队成员，使用通用dao，完成一个页面的开发，只需要建三个文件： 1、视图文件； 2、控制器类； 3、Service类 仅此而已，组员省心省力，不用去写任何配置文件，因为一切都基于命名约定：约定优于配置。 ================================================================================== simple is better，简单就是美 谁的孩子谁抱走，流水线码农不能揽架构师的活，架构师也不该把自己的任务仍给流水线码农。 在我们公司，架构师跟流水线码农界限分得非常清楚，架构师闲的时候可以做点流水线码农的活，但是流水线码农绝对不可以干架构师的任务。 ================================================================================== 战斗机设计师只应该设计图纸，不应该去拧螺丝钉； 战斗机组装工人更不可能去设计战斗机图纸，他只可以拧螺丝钉。 我这么说并不是看不起流水线码农，只是实事求是而已，我相信每个流水线码农，在经验丰富，创新能力、独立解决问题的能力提高以后，都有潜力成为架构师。 |
| 返回顶楼 | |
|
发表时间：2012-02-24
youarestupid 写道 那你们公司的软件架构师起到了项目经理的作用了，应该要求加薪。 项目经理没权利从技术角度决定需求的可行性 |
| 返回顶楼 | |
|
发表时间：2012-02-24
youarestupid 写道 我们公司确实是一个我这样的半吊子软件架构师 + 几个游手好闲的流水线程序员。 不过写文档、分析需求这些任务也不是软件架构师的任务范畴！ 架构师在整个项目的生命周期,都是全程核心,几乎所有流程都得参一脚的 唯独代码 不用太多写 |
| 返回顶楼 | |
