午夜小酌-----大话面向接口编程

白居易有诗云：“小酌酒巡销永夜，大开口笑送残年。”今天来和大家分享下我对面向接口编程的新认识和新理解。个人能力有限，文章有不足的地方，欢迎大家在评论区进行指正。

业务层开发的认识

一、业务层的微观原理和宏观表现：
1. 业务层的意义不是改变方法名称：在理解业务层的时候我们一定要明确一点那就是何为业务，在最初理解分层以及层与层之间通过接口回调的过程时，认为业务层只是对Dao层逻辑的简单封装，业务接口中的抽象方法基本和Dao层接口的抽象方法在返回值以及参数方面有类同，业务层接口方法内部的实现和直接回调Dao层接口没有两样（业务层只是Dao层的门面），很显然这种理解是不到位的，分层的意义绝不是为了改变一下业务方法的名称。
2. 业务层方法的定义应该面向业务需求：在定义业务层接口方法的时候，我们其实不是面向Dao层而应该是根据具体的业务逻辑来定义相关抽象方法的。业务层方法在调用者看来对应的是一个业务逻辑实现，但方法的具体实现其实则是若干Dao层接口方法的回调，也就是说在业务层我们可以引入若干个Dao层的接口引用，通过各个接口方法的回调进行组合，宏观表现就是业务逻辑功能的实现。

二、不要把属于业务层的逻辑判断放到controller层：谈到分层，我要说的一点就是一定要明确各个层对应的任务，Model层对应的是数据处理，Controller对应的调用业务层方法返回数据到View层，而View层负责数据呈现。在Controller层好多人可能会将一些个逻辑判断加入其中，这样的编码是不合理的，在项目开发后期会有很高的维护成本而且不易于功能扩展，所以一定要将所有的逻辑判断放到业务层来实现。

什么是可扩展性

一、功能扩展“未雨绸缪”：假如我们在一个类中引用的是一个接口引用而不是把接口的具体实现作为参数传入，那当你这样编码之后，代码本身便具有了很强的扩展性。如何来理解呢，如果你传入的是一个接口的具体实现，那么你的参数只能是这个实现类，其他的实现类想传入是不可能的。但如果是接口引用传参那就不一样了，你可以传入任何该接口的实现类，每一种新的实现类对应着不同的抽象方法实现也就代表着不同的功能，如果你需要扩展新的功能，那么只要重新定义一个该接口的实现类在方法中写入新的逻辑然后传入其中一样的回调对应的就是新的功能。

二、实现扩展的两种方式：实现功能扩展有两种方式，第一种方式是不同的接口引用进行方法回调的组合（业务层的底层实现），第二种方式是接口的继承组合以及更多实现类的传入。这两种方式的每一种都可以实现系统功能的扩展，二者甚至可以相互协调实现更多的业务逻辑组合。

从定义环境变量的角度理解解耦的意义

一、从变量的设定意义谈解耦：我们都知道在最开始学习Java的时候我们首先要做的就是安装JDK并配置环境，在配置环境变量的时候我们往往会创建一个路径的代名词（环境变量），然后在Path里边进行相关引用配置。这种方案的好处就是假如我们的路径发生了变化我们只需要修改一下环境变量的路径就OK了，而Path里边的配置我们完全不用去管，这就是维护性，通过环境变量的引入我们使得Path配置和环境变量代表的路径实现了解耦，使得后续路径变更的时候维护配置起来更简单容易。

二、模块复用性以及可维护性：上边谈到了解耦对项目后期可维护性的意义，这里大多数指的是配置文件的引入。另外一个方面就是面向接口实现的复用性，通过分层我们实现了业务层和数据层以及控制层的分离，由于各个层对应的都是完全“本色出演”，高度内聚，所以我们完全可以将业务层的逻辑用在不同的呈现平台上这就是复用性（桌面应用和Web端）。

谈谈控制反转实现的完全解耦

一、完全解耦的三个对象：在谈解耦的时候往往需要一个媒介，比如层与层之间的解耦我们借助的是接口引用，JDBC数据库连接我们借助的是.properties配置文件。所以在谈解耦的时候我们要明确有三个对象，待解耦的两个对象以及一个中间媒介，缺一不可。

二、完全解耦的理解：我们知道面向接口编程使得接口的具体实现和调用方解耦，但是在调用方内部仍然有接口引用，所以算不上完全解耦，完全解耦指的是两个功能模块没有一点联系。而实现这种完全解耦的方案就是引入第三方媒介（Spring中的BeanFactory）,通过这种IOC方式我们会发现调用方的代码中完全找不到被调用方的任何信息，我们只是和BeanFactory进行交互，这就是完全解耦。

总结：

知识的学习讲究的是循序渐进，但不论如何都要不停的思考总结。多看，多想，多动手实践只有这样才能真正把知识融汇贯通。