【无标题】

这里解释为什么我们要先写接口再写实现类：使用接口是为了调用与实现解耦，带来的好处是可以各干各的。

先从工序上说，你在写上一层的时候，会用到下一层提供的逻辑，具体表现形式就是各种各样的service类和里面的方法。上一层开搞的时候，一定会知道的一个事是下一层会干什么事，比如“将传入编号对应的人员信息设置为离职”，但下一层的代码不一定已经一行一行写出来了。所以这会儿需要有个接口，让写上层代码的人先能把代码写下去。有各种理由可以支持这种工序的合理性，比如一般来说，上一层的一行代码会对应下一层的好多行代码，那先让写上层代码的人写一遍，解决高端层面的bug，会提高很多效率。

再从抽象角度说，不同业务模块之间的共用，不一定是共用某段代码，也可能是共用某段逻辑框架，这时候就需要抽象一个接口层出来，再通过不同的注入逻辑实现。比如模块1是登记学生信息，模块2是新闻发布，看上去风马牛不相及。但分析下来如果两个模块都有共同点，顺序都是1、验证是否有权限 2、验证输入参数是否合法 3、将输入参数转化为业务数据 4、数据库存取 5、写log，那就可以写一个service接口，里面有上述5个函数，再分别写两个service实现。具体执行的时候，通过各种注入方法，直接new也好，用spring注入也好，实现不同的效果。

这样做的另一个目的是为了后期的维护。当软件全部编好了，测试好了，然后给用户装好了，但是过一段时间，用户用着不爽，他又让做软件的人改变一些功能，这样软件开发人员只需要改实现类里面的代码，也就是只用改一个包下代码，不用这个包改一下，那个包里的代码还要改。因为项目大了，代码就是成万上亿行，用了接口的话，就起了这个作用。

另外，不用接口的话，假如修改了dao中的代码，因为service引用了dao中的类，那么也要改变service里面的代码，改完之后要重新编译运行，当项目比较大的时候，编译和运行很浪费时间的，而且会产生一些意外，本来只要编译dao中的代码，现在不光要编译dao中的代码，还要编译service。因为你不用接口，间接着action里的代码也要改，因为action中引用了service中的类，到最后，就变成了，牵一发而动全身本来在各个层之间用了接口只需要改一处代码的，这下可好，全要改，举个不太恰当的例子：好比，我摔了一跤，小腿摔断了，小腿断了，因为没用接口，间接着，大腿也断了，接着，屁股开花了，接着，上身也感染了。最后gg了。可能不太恰当，但是有助于你理解。

实在理解不了，你就记住这句真理：使用接口是为了调用与实现解耦，带来的好处是可以各干各的。