Javaweb项目有Service层和Dao层的情况下，为什么要额外加入他们的实现类（imp），而他们本身缺作为接口，不直接写方法？

问题出现场景

1. 最近练习Javaweb项目，在跟随视频练习的时候。发现与我之前学习时候很多不同的地方。这里是一个关于实现类的问题。
2. 在项目中，Service 层和 Dao 层，这两个层本身不在写实际的代码内容，而是作为一个接口，同时，编写一个他们的实现类，在他们的实现类内写一些实际的代码。而他们本身仅仅是调用这些实现类内的方法。
3. 很显然，Service 层和 Dao 层本身是可以直接写实际的代码的。
4. 同样的，存在即合理，那他们存在的合理性又是什么？

问题的思考

1. 首先是一些自己的理解：还是解耦，分层必然增加代码， 视频中也提到了解耦这两个字，但是直接带过了。所以，可能还是为了接口和实现层各干各的？
2. 这个东西是不是必须存在的？感觉好像少了也没什么影响。。
3. 用与不用的优缺点各是什么？用的优点不知道，不用显然可以少写代码…

问题的解决

1. 首先这是个选择题，根据场景选择，可以使用，也可以不用。 当项目比较小的时候，可以选择不用。尤其是一个接口只有一个实现的情况下，可以选择不用。
2. 但是如果项目比较大，而需求的制定者跟代码的实际开发者之间的交流方式是，需求指定的人说了一个要求，我要一个方法，我给你几个参数，你给我返还一个什么值，它不关心你是如何返还的，用的什么算法。但是算法是可能最后被新的算法替换掉的。
   举个例子：手机充电，一般插头，数据线是可分离的。你安卓跟三星的数据线可能不能公用，因为手机那头的接口是不一样的。但是接插头的那一边的接口是一样的。有一天，你安卓的一款手机有用了三星手机的接口。这时候，对于一根数据线，你不需要改跟插头连接的那一边。只用改跟手机连接的那一端就行了。
3. 这是为了应对以后可能出现的 " 万一 "，万一以后接口的实现变多了。。
4. 所以，使用接口实现类的初衷是为了解耦，和便于后期更改的方便。
5. 实际上，很多中小型项目有没有这个东西，影响不是很大。有了不会带来额外的好处，没有很明显的减少了代码量。
6. 但是，对于大型项目，还是沿用这种方式，避免以后可能出现的错误。

问题的总结

1. 说了这么多，其实整理的不是很明白。在找参考资料的时候，都说用接口的好处参加工作年份或者写的代码量足够多了之后才能体会到。这样来看，我还没达到解封成就的条件…
2. 别人都这么用，老师也这么讲，为了避免不可预知的错误，还是选择暂时使用。
3. 如果以后很明确的了解如何选择是否使用接口的实际工作场景，会更新博文。