From Apprentice To Artisan 一书个人理解

在读这本书之前其实是没怎么看过Laravel的源码的，官方文档虽然有写，却感觉到了枯燥，所以其实对依赖注入，IoC容器，服务提供者的理解还是很浅显，即使知道了他们的原理却不知道该怎么运用。读完下来跟着作者一起看源码，写实现，扩展，才把之前的知识空缺给补充上，才知道Laravel的源码简直就是一本框架实现原理教科书，同时美轮美奂的注释和结构又区别于教科书的枯燥，强烈推荐大家看看。接下来说说读完之后对书中提到概念的理解，也当作一遍复习，有理解错误的地方希望各位指出。

依赖注入

第一次接触Laravel的时候，我也被依赖注入这个名词搞的头晕脑胀，查找了许多相关资料，发现有许多喜欢和IOC容器的概念混在一起讲。但其实它们解决的问题是不一样的。依赖注入模式（Dependency Injection ，简称DI，也成为控制反转模式，简称IOC）。

依赖注入主要解决的问题是：早期通过工厂模式解耦实例化过程，但当依赖的对象越来越庞大的时候，工厂也变得难以维护，依赖注入将对象的实例化从内部转到外部，但依旧是手动将依赖注入。

IOC容器解决的问题：将手动依赖注入变为自动依赖注入，通过反射实现。

在依赖注入这一章作者首先说明了依赖注入和IoC容器的关系，因为初学的时候这两个概念很容易混在一起搞不清楚，关键就是实现依赖注入并不需要IoC容器，因此在学习的时候切记不要混淆了概念而使得学习事倍功半。

为什么

然后是为什么需要使用依赖注入？主要是将职责分离到不同的类中（解耦），当使用了接口在注入时进行类型声明的时候，可以轻易切换实现类，并且测试起来也更方便（使用Mockery模仿库）。

如何实现

如何实现依赖注入，就只是将不属于类1职责的部分挪出来，新建一个负责这部分职责的类2，将这个类2的实例“注入”到类1中，由类1按需调用。

更进一步

本章第三节讲了一个例子巩固理解，提到了Contract约定（其实就是接口）。写接口虽然麻烦但是它带来的好处有很多：可以轻易切换实现，可以不需要具体实现，通过模拟进行快速测试。似乎接口和依赖注入带来的好处很像，其实就是因为依赖注入将耦合的代码分离成了接口，间接获得了接口的功能。

第四节讲了开发时要灵活变通，不必死死遵循各种原则，小项目不必使用接口也可以运作的很好，收益不高。大项目使用接口的收益会很大。

IoC容器

开篇先讲了容器主要作用是来管理依赖注入，容器是Laravel的核心，Application类就是继承自Container类。

容器具体解决什么问题？一是通过App::bind绑定接口的实现，可以轻易地切换接口的具体实现，所以容器就是一个用来存储各种绑定的地方。singleton和instance区别不大。Laravel的容器类甚至可以抽离出来单独使用。

二是Laravel容器使用了PHP“反射”的机制这个强大的特性，反射是一种运行时探测类和方法的能力。

反射的例子

在作者的例子中UserController依赖于StripBiller 。当StripBiller 没有在容器中绑定的时候，反射机制就会发挥作用，先探测StripBiller 所需要的依赖，然后递归解决，最后返回StripBiller的实例。

有了反射，我们可以免去写大量绑定的烦恼。但是当使用接口进行依赖类型声明的时候，我们需要将具体的类绑定到接口上，因为接口是无法被实例化的。

最后，若想深入，请读Illuminate\Container\Container源码（还没读）。

接口约定

第三章主要讲的是接口，强类型弱类型的知识。

服务提供者

前面提到的容器需要绑定具体实现类，而服务提供者就是负责绑定的地方。在app/config/app.php中可以查看所有的服务提供者。

我们在register方法中写相关的绑定，因为在

“程序框架刚启动时，所有在你配置文件里的服务提供者的 register 方法就会被调用”。

另外不要在register中使用任何服务，这个方法只用来绑定。

“所有关于绑定类后续的判断、交互都要在 boot 方法里进行”。

服务提供者并不是必须的，因为服务提供者只是一个用来自动初始化服务组件的地方，一个方便管理引导代码和容器绑定的地方。并不是你非要发布个什么软件包才需要服务提供者，他们只是非常好的管理代码的工具。使用它们的力量去管理好应用中的各个组件吧。

服务提供者是延迟加载的。

服务提供者还有另一个方法boot，这个方法在所有register方法执行完毕之后触发，在启动方法里面，你想做什么都可以。

最后，作者建议阅读各种Providers的源码，如FilesystemServiceProvider和 ExceptionServiceProvider 。

”有人会说核心服务提供者和应用程序容器就是 Laravel 。Laravel 其实是将这么多不同部分联系起来，形成一个单一的、内聚的整体的这么一个机制。拿建筑来比喻，那些服务提供者就是框架的预制模块。”

作者的例子举的很贴切，不时提醒我们容易忽略的细节，同时不要被条条框框限制住，嗯，毕竟是Laravel框架的Creator。后面还有几章对框架的深入使用，几章关于SOLID原则。

SOLID部分

之前有看了不少各种各样的关于SOLID的讲解，教学。而自己真正理解了的可能只有单一职责原则，其他几个的概念基本处于模糊不清的状态。看了这部分之后，终于加深了对它们的理解，而核心是knowledge知识(后来才知道是迪米特原则)，即用一个类需不需要懂得这种知识来区分边界，而这些原则的目的就是达成这一目标。当一个类知道的太多的时候，它就打破了某些原则。

5个原则紧密相连，如果其中一个原则没有被遵循，那么其他大部分（可能不会是全部）的原则也会出问题。

Single Responsibility（单一职责）：5个原则中最好理解的原则，即一个类只负责他职责范围内的事，一个类不需要知道与他职责无关的。
典型例子：控制器只需要负责接收和转发请求，不需要知道如何处理请求，处理请求可通过依赖注入请求处理类进行操作

Open Closed(开闭原则）：易于扩展，对修改关闭。
典型例子：复合搜索的Filters类，不再用if判断是否有该搜索条件，然后添加where语句，而是使用模板模式。Github示例代码

Liskov Substitution（里氏替换）：如果一个类使用了一个接口的一个实现类，那么该接口的任何其他实现类也可以被这里直接使用，不用做出任何修改。

典型例子：Laravel中的Contract，在应用中使用接口作类型提示，在容器中将特定实现类绑定接口，可自由替换。

Interface Segregation（接口隔离）：接口隔离原则规定在实现接口的时候，不能强迫去实现没有用处的方法。你是否曾被迫去实现一些接口里你用不到的方法？如果答案是肯定的，那你可能创建了一个空方法放在那里。被迫去实现用不到的函数，这就是一个违背了接口隔离原则的例子。

典型例子：这个原则在PHP的官方session实现中被违反，可能是5个例子中重要性较小的一个。（或者是我水平不够还没达到这个层次）

Dependency Inversion（依赖倒置）：该原则要求高等级代码不应该依赖低等级代码，抽象定义不应该依赖具体实现。

低级代码用于实现基本的操作，比如从磁盘读文件，操作数据库等。高级代码用于封装复杂的逻辑，它们依靠低级代码来达到功能目的，但不能直接和低级代码耦合在一起。

典型例子：
1.认证用户类，需要查询用户数据库表，中间抽象出一层用户操作类，使得认证用户类不依赖于数据库类，可轻易改变数据库类的实现
2.工厂模式，高等级代码不直接依赖于低等级的实现，而是依赖于工厂。

Java中的另外几个设计原则:迪米特原则（最少知道原则，knowledge划分界限），合成复用原则（尽量使用组合，而不是继承）。