|
锁定老帖子 主题：对于接口越来越迷茫
精华帖 (0) :: 良好帖 (6) :: 新手帖 (4) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2012-02-23
抛出异常的爱 写道 现在不用非得写接口了......
不过几年以前的确是需要..... 所以SERIVCE,DAO之类的传统都是要写接口的. PS:举个例子, 一个点击操作, 需要25个if判断, 5次遍历, 三个层(action,service,dao) 至少五种页面请求过滤器, 三个日志分析拦截器, 一个统一的主键生成工具类 硬性要求每个function代码行数要少于50行. 以上业务会有经常的变动 不知道如果需求变更时 要在哪个类哪个function进行改动 才能更好的完成业务变更 如上的工作会有很多....... 你们如何去组织你们的代码 让你们的代码本身会说话? 一个serivce一个方法2000行写不写接口没意义 经常性改接口的原因大多是由于,接口数量太少 什么乱七八糟的鸟儿逻辑，不懂不要装懂！ |
| 返回顶楼 | |
|
发表时间：2012-02-23
抛出异常的爱 写道 现在不用非得写接口了......
不过几年以前的确是需要..... 所以SERIVCE,DAO之类的传统都是要写接口的. PS:举个例子, 一个点击操作, 需要25个if判断, 5次遍历, 三个层(action,service,dao) 至少五种页面请求过滤器, 三个日志分析拦截器, 一个统一的主键生成工具类 硬性要求每个function代码行数要少于50行. 以上业务会有经常的变动 不知道如果需求变更时 要在哪个类哪个function进行改动 才能更好的完成业务变更 如上的工作会有很多....... 你们如何去组织你们的代码 让你们的代码本身会说话? 一个serivce一个方法2000行写不写接口没意义 经常性改接口的原因大多是由于,接口数量太少 一个service2000行这个我深有体会， 如果业务层的业务代码行数过多确实说明功能拆分得不是太好，既然都面向过程了，写接口还有啥用 不过接口数量太少这句话的意义没太理解。 功能划分得不细会导致实现类的代码频繁修改，修改接口倒是没见过。 修改接口的情况大致也就这么几种吧 添加方法 修改方法的参数 修改方法返回值 增加方法抛出的异常 这个。。貌似做法比较奇怪吧。。。 |
| 返回顶楼 | |
|
发表时间：2012-02-23
最后修改：2012-02-23
应该抽成接口的没有抽成接口
而是使用了一个巨大的接口把请求的所有细节全封死在service中 每个SQL只对应一处使用. 这里有用户验证, 那里也有用户验证 这里有定单统计 那里也有定单统计 不在一个SERVICE中就要写到好几个DAO中 是由于你不知道这内个类似的方法 有没有合起来的必要. 一个ACTION中Selcet列表也需要在Action中写明调用的service, 带翻页请求与不带翻页请求写出不同的SQL page类 从页面一杆子扎到底 用户权限从ACTION带到底, 如果想以上的办法解决 就有必要写些特别的代码 这类代码有时用ctrl点不进去 有时在代码堆中会被忽视. 没个接口进行指示. 跟本不知道这个类会不会被使用这些功能 当然你也可以用@Service(p=10)注解方式来完成这些功能 但是我还是喜欢Interface这类的东西. |
| 返回顶楼 | |
|
发表时间：2012-02-23
在J2EE的应用程序中编写接口，与实际的业务场景有很大的关系。我这里有一个比较现实的例子可以描述一下。
我们在做一个美国项目的时候，有一段业务逻辑需要连接到美国的另外一个应用程序获得一个状态信息，这个远程调用非常慢，通常返回一个结果需要10分钟。比较恶心的一点是，这个状态信息是业务逻辑的关键信息，我们不得不根据不同返回情况来编写后续业务。 这时候接口的作用就体现出来了。因为这个Service Call一旦是一个接口，我们就可以使用其他的实现类来代替原本非常恶心的Remote Call的实现，从而使得我们能够从非常慢的一个远程调用中解脱出来。 所以，在典型的应用程序中，使用接口进行编程的核心作用是可以在适当的时机切换不同的实现方式从而是整个过程变得更为可控。 当然，另外一点，楼主也可以参考一下。楼主可以去浏览一下所有的设计模式，看看这些设计模式的应用是不是绝大多数都建立在接口的基础之上？所以接口的使用在很大程度上是最佳实践的一种集合体现。 之前的一些说法，有的相对比较靠谱，有的则毫无逻辑。希望楼主在参考时加以甄别。 |
| 返回顶楼 | |
|
发表时间：2012-02-23
即使小项目，你不用单元测试吗？没有接口，如何做？
|
| 返回顶楼 | |
|
发表时间：2012-02-23
最后修改：2012-02-23
downpour 写道 在J2EE的应用程序中编写接口，与实际的业务场景有很大的关系。我这里有一个比较现实的例子可以描述一下。
我们在做一个美国项目的时候，有一段业务逻辑需要连接到美国的另外一个应用程序获得一个状态信息，这个远程调用非常慢，通常返回一个结果需要10分钟。比较恶心的一点是，这个状态信息是业务逻辑的关键信息，我们不得不根据不同返回情况来编写后续业务。 这时候接口的作用就体现出来了。因为这个Service Call一旦是一个接口，我们就可以使用其他的实现类来代替原本非常恶心的Remote Call的实现，从而使得我们能够从非常慢的一个远程调用中解脱出来。 所以，在典型的应用程序中，使用接口进行编程的核心作用是可以在适当的时机切换不同的实现方式从而是整个过程变得更为可控。 当然，另外一点，楼主也可以参考一下。楼主可以去浏览一下所有的设计模式，看看这些设计模式的应用是不是绝大多数都建立在接口的基础之上？所以接口的使用在很大程度上是最佳实践的一种集合体现。 之前的一些说法，有的相对比较靠谱，有的则毫无逻辑。希望楼主在参考时加以甄别。 1.一般跨系统之间的通讯都会使用技术框架去解决，即接口是比较适合公共平台或者技术框架类型的系统中(不牵涉具体的业务逻辑)用以替换技术上的实现，你的service开始完全不需要抽象成接口，完全可以在具体的service实现类里面调用框架的接口去做这个切换(通过配置文件) 2.mock和stub也可以解决你描述的场景，不需要接口 3.如果存在业务上的多实现完全可以通过后期的重构再抽象出接口，业务上的多实现依赖人对需求的不断认知和理解，是个渐进相对缓慢的过程，而且这样的场景并不多见，也不见得凡是出现if else就是丑陋糟糕的设计，不需要初期针对每一个service都抽象成接口 ps:我个人认为跨系统之间的调用之所以初期比较适合抽象成接口最主要的原因是由于是其它系统的代码，无论是服务提供方还是调用方无法控制对方是如何使用或者实现的，修改实现都依赖于对方的原因，如果不是跨系统即代码在自己系统中维护，开始抽象出接口是不必要的 thx |
| 返回顶楼 | |
|
发表时间：2012-02-24
lvjun106 写道 interface: "like -a"
撇开实际业务不谈， 项目中经常在JUNIT中的MOCK中用到接口类，SPRING创建FactoryBean,代理类，AOP等等都用到接口类。 系统间的集成，系统内部各功能间的相互调用，无不使用接口。 所以请面向接口编程。我所说的接口也包括抽象类啊~~~呵呵。 1.项目中经常在JUNIT中的MOCK中用到接口类，SPRING创建FactoryBean,代理类，AOP等等都用到接口类。 这都是spring1.0的时候的事儿了，现在都3.1的时代了，多少年前就可以proxy-target-class了，使用cglib实现的。jdk的动态代理原因强制使用接口都是多少年前的老黄历了 2.系统间的集成，系统内部各功能间的相互调用，无不使用接口。 这是用接口的理由？有了功能调用就该用接口？ 3.所以请面向接口编程。我所说的接口也包括抽象类啊~~~呵呵。 抽象类和接口混为一谈，很容易出现滥用继承的情况，建议你好好看看effective java |
| 返回顶楼 | |
|
发表时间：2012-02-24
downpour 写道 在J2EE的应用程序中编写接口，与实际的业务场景有很大的关系。我这里有一个比较现实的例子可以描述一下。
我们在做一个美国项目的时候，有一段业务逻辑需要连接到美国的另外一个应用程序获得一个状态信息，这个远程调用非常慢，通常返回一个结果需要10分钟。比较恶心的一点是，这个状态信息是业务逻辑的关键信息，我们不得不根据不同返回情况来编写后续业务。 这时候接口的作用就体现出来了。因为这个Service Call一旦是一个接口，我们就可以使用其他的实现类来代替原本非常恶心的Remote Call的实现，从而使得我们能够从非常慢的一个远程调用中解脱出来。 所以，在典型的应用程序中，使用接口进行编程的核心作用是可以在适当的时机切换不同的实现方式从而是整个过程变得更为可控。 当然，另外一点，楼主也可以参考一下。楼主可以去浏览一下所有的设计模式，看看这些设计模式的应用是不是绝大多数都建立在接口的基础之上？所以接口的使用在很大程度上是最佳实践的一种集合体现。 之前的一些说法，有的相对比较靠谱，有的则毫无逻辑。希望楼主在参考时加以甄别。 这个说法很滑稽，用了接口就能解决一个remoting 10分钟？如果你仅仅是需要cache一下，那和接口也没有关系。典型的remoting架构里面，一个proxy模式是很正常的，所有底层的工作都应该在这个层面进行，过去的确什么模式都有，corba的代码生成，ejb的接口，至于各种ws*和rest的服务，说实话没有接口有个文档一样可以访问或者通过自描述来导入服务，强制的接口越来越没有必要。 最后：所以，在典型的应用程序中，使用接口进行编程的核心作用是[b]可以在适当的时机切换不同的实现方式从而是整个过程变得更为可控。 这句话就是在骗自己，其实99%的时候，这是不可能的。尤其是写个xxxdao然后写个xxxdaoimpl这种的，用了jdbc的指望以后换jpa、mybatis或者hibernate，写了xxxservice再写个xxxserviceimpl然后指望通过配置就直接暴露服务的，都是在玩自己。。。 |
| 返回顶楼 | |
|
发表时间：2012-02-24
flashing 写道 downpour 写道 在J2EE的应用程序中编写接口，与实际的业务场景有很大的关系。我这里有一个比较现实的例子可以描述一下。
我们在做一个美国项目的时候，有一段业务逻辑需要连接到美国的另外一个应用程序获得一个状态信息，这个远程调用非常慢，通常返回一个结果需要10分钟。比较恶心的一点是，这个状态信息是业务逻辑的关键信息，我们不得不根据不同返回情况来编写后续业务。 这时候接口的作用就体现出来了。因为这个Service Call一旦是一个接口，我们就可以使用其他的实现类来代替原本非常恶心的Remote Call的实现，从而使得我们能够从非常慢的一个远程调用中解脱出来。 所以，在典型的应用程序中，使用接口进行编程的核心作用是可以在适当的时机切换不同的实现方式从而是整个过程变得更为可控。 当然，另外一点，楼主也可以参考一下。楼主可以去浏览一下所有的设计模式，看看这些设计模式的应用是不是绝大多数都建立在接口的基础之上？所以接口的使用在很大程度上是最佳实践的一种集合体现。 之前的一些说法，有的相对比较靠谱，有的则毫无逻辑。希望楼主在参考时加以甄别。 这个说法很滑稽，用了接口就能解决一个remoting 10分钟？如果你仅仅是需要cache一下，那和接口也没有关系。典型的remoting架构里面，一个proxy模式是很正常的，所有底层的工作都应该在这个层面进行，过去的确什么模式都有，corba的代码生成，ejb的接口，至于各种ws*和rest的服务，说实话没有接口有个文档一样可以访问或者通过自描述来导入服务，强制的接口越来越没有必要。 换句话说接口是纯虚的，纯虚啊，这个虚字是重点啊，每次查实现的。。。 最后：所以，在典型的应用程序中，使用接口进行编程的核心作用是[b]可以在适当的时机切换不同的实现方式从而是整个过程变得更为可控。 这句话就是在骗自己，99%的时候，这是不可能的。尤其是写个xxxdao然后写个xxxdaoimpl这种的，用了jdbc的指望以后换jpa、mybatis或者hibernate，写了xxxservice再写个xxxserviceimpl然后指望通过配置就直接暴露服务的，都是在玩自己。。。 另外代码量的增多其实让整个过程更不可控，java的程序员都太过渡设计了，考虑了太多没用的东西，举个例子，apache的httpclient3.1->4.x，最近再一比较python的urllib，全是眼泪啊。。。 |
| 返回顶楼 | |
|
发表时间：2012-02-24
只要有多实现的，就用接口或者抽象类。
|
| 返回顶楼 | |
