Welcome!
在第一章《关于教程——前后端分离》中我们对软件分层的初衷和设计模式做了初步的了解，控制层和模型层在目前的学习进度中我们也反复利用了很多次，我们还自己派生了验证层和服务层，层的作用本质上都是对代码、实现功能的归纳来实现结构清晰和功能解耦。学习到这里，我们不妨可以回顾一下之前的代码，看看是不是这样子。作者在初次接触分层这个概念的时候，一直处在一种跟着用但不知道有啥用、为什么这么用的状态，我相信很多读者学到这里，也有这种疑惑，你让我分层我分了，但是还是很懵。首先有一点要明确的是，即便你不分层，你依然可以开发一套可以上线的系统，但是，你这套系统绝对会是难以维护和扩展的系统。因为不分层的话，你的每一个类文件里要实现的功能就非常多，每个功能要实现的逻辑也会变得很复杂而且会存在重复实现某个功能的情况（比如不同类文件里都存在查询同一个数据的方法）。这种一个类同时承担了多个职责，同时又大量依赖其他类的情况，我们称之为低内聚、高耦合，而与之相反的就是最佳实践——高内聚、低耦合。这两个词相信大家都听过或者看过但是不知道是什么，标准的释义读者可自行搜索引擎，反正脱离了代码你也看不懂。这里我们以前面实现了的代码来尝试理解，比如说服务层下WxPay类。首先服务层的定位是提供某种特定的服务，服务层下的WxPay类是提供微信支付相关接口的调用服务，我们想实现的就是在其他地方只要调用这个WxPay类里的某个方法就能得到某个具体服务的结果，这个不难理解，但是实现起来就会有各种问题，举个例子，我们在前面学习中一开始只实现查询了一家微信支付商户产生的订单状态功能，如果你自己只有一家商户那很好办，照着代码抄就完事，那万一如果你同时有2家甚至3家往上的商户呢？又或者多个应用绑定同一个微信支付商户（这时候APPID会不一致），现有的代码是不是无法实现了？像这种情况，解决办法只有一个，那就是尽量把实现类的职责做得足够单一，单一到实现类只做一件事，就是负责实现功能，至于实现功能所需要的参数，都交给调用方来提供，想到这里，我们第一个想到的办法就是让服务类接收一堆的变量，这个方式早期是没问题的，但是后期作者就遇到了一个问题，在其他地方复用这个方法的时候，经常需要查看变量的传递顺序和数量，某一天我重构了这个服务类，参数的数量和顺序变了，调用的地方全部得修改。我们解决了参数变化的问题但是没有解决参数传递和接收的问题，这时候我们就需要在这个基础上再思考怎么解耦，我们把参数传递和接收这件事改成类成员属性赋值的形式来实现（面向对象），比如WxPay类下实现的config()方法，看起来是改变变量，实质也是改变了运行逻辑，改变了要读取的配置对象。我们在外部调用时只需要明确一个订单号，至于其他参数，通过WxPay暴露出去的方法来设置，WxPay的内部只管调用，自己的成员属性当前是什么不关心。这里读者可能会觉得，这里的WxPay的业务逻辑不复杂，还好理解，如果是复杂的，怎么办？比如说一个类里面同时依赖了好几个类，还有一堆业务逻辑判断。这里答案就是就是一层一层往上抽象，不停的把公共的逻辑提取出来成一个类，外部只和最“底层”的实现类打交道，这个实现类肯定有一个特点，就是高内聚、低耦合。说了那么多，这和分层又有啥关系呢？答案就是层是由一个个这种高内聚、低耦合的类组成的，而层与层之间又是一种高内聚、低耦合的关系，这样一路下来，你的整个系统就会变得很容易定位问题，也很容易扩展，即可维护、可扩展。如果读者还是理解不了以上内容，那么可以暂时先放弃理解这些概念和思想，你只要不停的追求代码可复用性即可，在这个过程中你就会不知不觉地对代码层层提炼。还有的读者可能会说道理我都懂了，可还是不会写，那么这里作者介绍一个终极大招——遇事不决，重构即可。没有人能一下子写出完美的代码，而事实上完美的代码也不存在，再好的代码也总能挑出毛病，我们所遵循的设计模式也都是前人通过不断重构和实践总结出来的，包括我们专栏中的代码，后面我们也会因为一些契机对现有的代码进行有目的性的重构。