为什么业务层的接口和实现方法要分开写

假设我现在定义了一个接口，但是我在继承这个接口的类中还要写接口的实现方法，这看起来不是太麻烦了，那我不如直接就在这个接口中写实现方法岂不是更便捷，还省去了定义实现类？我甚至都可以把持久层的东西跟业务层的东西整在一起，再过分点是不是干脆逻辑层,业务层，持久层都杂糅在一起好了，这样不是更省事？持续堆屎山就好了，反正项目能跑就好了，这样对吗？

我觉得并不是，Java是针对接口编程，制定编程规范，这样拥有较好的延展性，诚然，当我们在做小项目的时候，使用接口，实现类，看起来还比较麻烦，但是做大项目就不一样了，针对接口的编程就很重要了，这有利于维护和扩展。而且在分工上也比较容易配合。比如，我要调用service层方法，直接通过接口调用方法就好了，完全不必关心方法的实现，可以由团队的其他人来做。另外，不针对接口编程，做的只是一个项目。而针对接口编程，可以做成产品，然后在产品的基础上构建项目。相同领域的项目，很多只是具体实现的细节不同而已

接口与实现分开设计好处是非常多的，可以更好的实现各功能模块分开，对软件改错、维护、更新有非常大的帮助。如果业务有变动，只需要对不同的业务的实现类进行修改就可以了，不会影响其他业务的实现类。大大的降低了 代码耦合度，也提高了代码的可读性。

当然了,这个最多是在你学的时候，你自己写项目写着玩，接口和实现方法写在一起那倒是没问题，没有人会管这种东西,但是你真正拿到在公司里上班来说的话，我认为这样不对，接口和实现类分开来写，固然是代码多一点点，可是，在实际开发中，绝对是更好改错更新维护的，接口和实现类写一起，项目出问题，责任谁来担？就算运气好不会出问题，老板看到这种代码，当时就记住你了，第二天会因为左脚先跨进公司门被开除，所以我认为就算是平常自己的练习写项目，也要养成接口和实现方法分开写的好习惯，加油吧