接口回调的问题，希望大牛们能解答...
我看一些代码，当处理一些业务逻辑时往往是先定义一个接口，然后去写这个接口的实现类，再去servlet中调用这个实现类的对应方法，我的问题就来了，为什么不直接在servlet中去写相应的业务处理，而是通过接口的方式去实现，这样写有什么好处呢？？


希望大伙给点说明，高分奉送...
------解决方案--------------------
传送门之一


传送门之二
------解决方案--------------------
不了解的再发私信给我。
楼上那些屌丝。。。。
------解决方案--------------------
这就是依赖倒置原则（Dependency-Inversion Principle）

要依赖于抽象，不要依赖于具体。

目的是降低耦合。
------解决方案--------------------

引用:

这就是依赖倒置原则（Dependency-Inversion Principle）

要依赖于抽象，不要依赖于具体。

目的是降低耦合。

++
这种设计是面向对象设计的原则问题,如果你直接在servlet
中实现业务逻辑,就依赖于具体了,但是实际中需求是在变换的!
依赖于具体也就意味着你完成的大部分代码会重写,重构!
------解决方案--------------------

引用:

引用:这就是依赖倒置原则（Dependency-Inversion Principle）

要依赖于抽象，不要依赖于具体。

目的是降低耦合。
++
这种设计是面向对象设计的原则问题,如果你直接在servlet
中实现业务逻辑,就依赖于具体了,但是实际中需求是在变换的!
依赖于具体也就意味着你完成的大部分代码会重写……

++1。
好处很多.学习了、。
------解决方案--------------------
行为功能的抽象和封装。
其目的有两个：
1. 封装后，一般可以将封装好的部分，脱离使用者Servlet，替换到别的应用环境中。
2. 便于更换程序的底层实现。比如，更换数据库，那么Servlet的代码不用动，只更换相关实现类的代码即可。

其他的方面，就不多说了。
------解决方案--------------------
比如，代码复用 。
一个Servlet里面用了，查询当前用户所在组的权限信息，另一个Servlet里也用到了。
那么，封装好这个查询功能，代码可以复用，没必要两个Servlet里，写相同的实现代码。
------解决方案--------------------
扩展性 !!!!!!!
------解决方案--------------------
其实主要是MVC的思想和好处，高内聚、低耦合,方便后期的维护，提高代码的复用性！