From Apprentice To Artisan 原文翻译在线观看
在读这本书之前其实是没怎么看过Laravel的源码的，官方文档虽然有写，却感觉到了枯燥，所以其实对依赖注入，IoC容器，服务提供者的理解还是很浅显，即使知道了他们的原理却不知道该怎么运用。读完下来跟着作者一起看源码，写实现，扩展，才把之前的知识空缺给补充上，才知道Laravel的源码简直就是一本框架实现原理教科书，同时美轮美奂的注释和结构又区别于教科书的枯燥，强烈推荐大家看看。接下来说说读完之后对书中提到概念的理解，也当作一遍复习，有理解错误的地方希望各位指出。
依赖注入
第一次接触Laravel的时候，我也被依赖注入这个名词搞的头晕脑胀，查找了许多相关资料，发现有许多作者喜欢拿现实来举例，还和容器的概念混在一起讲。但我发现这样作用很小，因为当时我根本没明白。相反，我觉得直接掏出代码展示会更直观好理解。
在依赖注入这一章作者首先说明了依赖注入和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的讲解，教学。说实话真正理解了的只有单一职责原则，其他几个的概念基本处于模糊不清的状态。看了这部分之后，才知道SOLID五个原则之间其实是相互联系的，而核心是knowledge知识，即用一个类需不需要懂得这种知识来区分边界，而这些原则的目的就是达成这一目标。当一个类知道的太多的时候，它就打破了SOLID原则。
