看了下上一篇PHP学习笔记写的好像没有什么营养，只能说时间过的好快，转眼之间就到9月底了，说是29号有这方面知识的考试。孩子战战兢兢。只能早早整理相关知识。目前看大概有三块内容，我尽快在本周内复习完成。

这块内容主要是PHP的相关知识，就算在相关学习笔记了。

开发环境和工具

上一篇提到过了，基本上是LNMP或者LAMP，我最近做Laravel相关的东西甚至直接有官方配好的Homestead环境，所以这块基本上就是配着玩的。自己在云主机上装过一遍了，挺好的。还是难在PHP的编译安装上了，上一篇没有记录，个人感觉基本上拿着对应版本号的包去网上搜，然后照着做，基本问题不大。至于编辑器IDE什么的，自己看着弄吧，VS Code我是心累了，如今也就是拿来写写博客。

编程工具和扩展安装

略，主要是针对VS Code的。

PHP基础和动静结合

一个面向对象编程语言的基本组成部分大概就是一堆关键词，三种逻辑结构，还有自带函数、面向对象内容等等。感觉主要是后边两个部分有点需要看看，前面部分实在没什么可说的。

动静结合指的就是网页和PHP搭配处理请求吧，我印象中这块也没什么，毕竟动态请求处理自然而然就这样了。

PHP语法简介、异常处理和垃圾回收机制

异常处理可以用die()，直接输出一个字符串结束程序。

try正常的代码，catch处理相关的异常，throw抛出异常。简单来说就是函数抛出的一场有catch负责处理。

以上就是异常处理部分的相关内容。

垃圾回收机制主要是基于变量存储容器（zval）上的访问记录数，数为零，自然就会被释放掉。垃圾回收使用一个轮询删除函数来实现的。

函数式编程、面向对象编程、类加载、命名空间

函数式编程和面向对象编程，难度不高，主要是有个继承调用等等的关键字，这个部分的内容需要看，像是trait、final无法被重写和继承
命名空间主要是限制变量的名称重复这种现象，同时，可以用use关键字来给类或命名空间取别名。

编程规范、psr、编程范式

多读几遍PSR编程规范就行，没多少东西。

PHP执行原理、依赖扩展的加载和安装

执行原理方面，其实基本上是分成三层的，最底层的是Zend Engine，是一个用C语言写成的PHP核心，Zend Engine负责把PHP代码翻译成类似于Java在虚拟机中跑的那种东西，叫所谓的opcode。PHP其实最下层调用的还是C语言的相关函数，所以可以把PHP看成是在C语言上层的一个软件实现。

SAPI指的是实现了PHP和最上层应用程序的结构分离的相关结构，像是上面提过的CGI和Fast-CGI等，其实我也说不太清楚它究竟是干什么的，大概是个桥梁？

最上层就是编写的应用程序了，通过SAPI获得各种各样的调用方式。

依赖扩展的加载和安装部分略，这部分之后还会继续强调的。

PHP设计模式

课上主要讲了四种设计模式：简单工厂、工厂方法、单例和策略。

说实话之前完全没有接触过这块知识，只知道它有本黑皮书，写的很牛逼。尝试把这点东西啃下来。

简单工厂模式（静态工厂方法）

简单来说，这个模式一共有三种类，第一个是个抽象类，定义了产品的基本属性；第二个是具体产品类，继承了第一个抽象类，实现了具体功能；第三个是工厂类，这个类大概只有一个方法，还是静态的，它专门负责具体产品的实例化，简单来说就是写一个if或者switch判断，根据传入的参数来实例化对应的产品。

简单来看，它把类的功能逻辑和类的实例化部分分割开了，耦合度降低，同时，实例的构建者并不需要知道实例对应类的全名，只需要知道对应这个类的参数就行了，只要设计合理的参数（像是针对第四次和第五次圣杯战争里的阿尔托莉雅可以直接指代成Saber这个东西😂，懂的都懂），就可以十分便利地完成实例化工作。

但是缺点还是有的，首先，工厂类太重要了，负责了全部的实例化工作，一旦它崩了，整个系统就完蛋了；其次，每次增添新的产品实例化功能，都要修改工厂类的实例化方法，而且一旦产品多了，整个系统的类的数量和工厂类的实例化方法都会变得庞大，难以理解；最后，工厂类的静态工厂方法难以形成基于继承的体系结构，工厂就这么大，没法进一步扩展了。

工厂方法模式

这个模式是简单工厂模式的改进型，主要是对工厂类进行了改造，建了一个抽象工厂基类，规定了必须实现的接口，再针对具体的产品实例化构建相对应的工厂类，由实际的工厂类实现负责产品的实例化。

刚开始看完我还有点蒙，上一步好歹有判断语句来判断调用哪个产品类完成实例化，这个可是没有判断语句了啊，我怎么知道要用哪个产品类实例化啊？对，构建者确实不知道该用哪个实例化，但他知道该去哪个对应的工厂，这就足够了，毕竟现在一个工厂负责一种产品，那么只要去了工厂，就一定能拿到产品（有点类似于把上一步中的创建阿尔托莉雅变成去Saber工厂提货就行了😂）。

好处是，扩展性很好，想要扩展新产品，不需要改代码了，直接继承写对应的具体产品类和工厂类就行，把具体实例化的细节完全封在了工厂类里，创建者不需要知道产品的细节，只要知道去哪个工厂类完成实例化就行。

坏处是，可能类的个数要比上一个翻一番了，毕竟每次都是成对增加内容的，开销是有的；其次，抽象类的使用可能增加了理解难度，还可能用到一些比较不好理解的编程技术，实现变难了。

扩展向：① 抽象工厂类可以定义多个工厂方法，这样针对多种产品类可以有多种选择 ② 创建过的产品可以存在数组或列表中，若后续请求直接有创建过的产品，就可以直接给出，没有的话可以创建后塞到数组中，再给出。

单例模式

简单来说，有的类有只实例化出一个对象的需求，这种模式就应运而生了。

简单来说，要满足三点要求，第一，只有一个实例；第二，自动创建实例；第三，提供全局访问实例的方法。

注意的点是：首先单例类的构造函数是私有的，只有访问函数那一步，里面判断实例为空的情况才会调用构造函数。这样也防止了非法构建重复实例。其次访问实例的方法应该是公有的静态方法。最后实例化标志是一个静态私有成员变量，类型其实是个单例指针类型？默认是NULL。

优点是受控访问，节约系统资源，更可以进一步扩展到限定实例化数量的类的相关实现。

缺点是扩展性差，任务太重，GC容易被杀和乱用程序崩掉。

应用：唯一序列号生成器，防止生成的序号重复。

策略模式

总的来说，像是从A到B，有好多条道路，那么就可以把这好多条道路依次列出来，只要能完成从A到B的任务就好了。选择的权力完全交给使用方，系统本身不做推荐。像是一组排序算法、一组查找算法……都可以这么组织。

基本上就是先建一个类似接口的东西说明一下要实现的功能，再去具体继承接口完成相关功能即可。

优点是，算法可自由切换，不用使用判断语句，扩展也方便。

缺点是，策略类多了的话体积会很庞大，同时每个具体的策略都要对外开放调用权限。

PHP开源社区和开源包的管理，composer的使用

基本上就是几个网站上找动态链接库，composer目前大概掌握require和install命令就行，可能之后补充一个composer操作什么的？

结语

东西说多也不多，还是要注重基础。