面向对象5原则

单一职责原则（single-resposibility principle）

其核心思想为：一个类，最好只做一件事，只有一个引起它的变化的原因

开放-封闭原则（The Open-Close principle）

其核心思想为：对扩展开放，对修改封闭
软件实体（类、模块、函数）应该是可扩展的，但是不可修改的。也就是说，对于扩展是开放的，对于更改是封闭的。怎样可能在不改动模块源代码的情况下去更改它的行为呢？怎样才能在无需对模块进行改动的情况下改变它的功能呢？关键是抽象！因此在进行面向对象设计时要尽量考虑接口封装机制、抽象机制和多态技术。该原则同样适合于非面向对象的方法，是软件工程设计方法的重要原则之一

Liskov 替换原则（liskov-substitution principle）

其核心思想：子类必须能够替换其基类
子类应当可以替换父类出现在父类能够出现的任何地方

依赖倒置原则（dependency-inversion principle）

其核心思想：依赖于抽象
一个类不应该强依赖另外一个类，每个类对于另外一个类都是可替换的
1、高层模块不应该依赖于低层模块，二者都应该依赖于抽象。
2、抽象不应该依赖于细节。细节应该依赖于抽象。在进行业务设计时，于特定业务有关的依赖关系应该尽量依赖接口和抽象类，而不是依赖于具体类。具体类只负责相关业务的实现，修改具体类不影响与特定业务有关的依赖关系。

接口分离原则（interface-segregation principle）

其核心思想：使用多个小的专门的接口，而不要使用一个大的总接口
具体而言，接口隔离原则体现在：接口应该是内聚的，应该避免“胖”接口。一个类对另外一个类的依赖应该建立在最小的接口上，不要强迫依赖不用的方法，这是一种接口污染

异常

异常是运行中超出了你程序预期的一个东西。

异常就是一个意外，影响了你的程序正常运行。但是如果你用好异常，会让你的程序便于解耦，结构更加清晰明了。

异常对我们控制程序的流程来说非常重要。解耦了程序出现意想不到结果时信息传递的逻辑。每个业务模块发生异常最终通过 Laravel 的方便的异常处理，和友好的展示，并能根据情况来记录错误，这样让我们的程序更加健壮，方便开发和维护。

异常 vs if_else

把这个大函数分成了若干小函数，在这个小函数里面抛异常，大函数里面扑获异常，不用再一个一个的判断小函数的返回值

任何好的语言都应该提供完善的异常支持服务, 来使程序结构更优美可读行更好可维护,而不是靠一大堆的if else来控制程序的流程.

要有上下层的概念，在上下层逻辑处理中,throw 是 Current Role 反馈给 Upper Role，try/catch 是 Current Role 处理 Lower Role 反馈

分层

把业务逻辑处理部分抽象出来作为一层，这一层在M之上，C之下，名为 Logic

把可以作为公共的服务抽象出来作为一层，这一层不与任何一层耦合，仅提供自身的服务，名为Service
小到文件上传，下载，图片处理，储存
大到日志，错误处理，邮件，授权，队列，计划任务，支付，验证，加密，短信都可以做出单独的服务

业务变了，C层和M层都不需要改动，只需要改动中间的 Logic 就好了

验证

在Controller里面，做外部来的请求数据包的合法性校验和部分用户接口权限校验
用户相关逻辑放在logic层,做严格的数据合法性校验、业务逻辑约束校验、用户数据权限校验
在Model里面做数据的物理合法性校验

多态

多态性是面向对象设计的重要特性，它展现了动态绑定的功能,多态的功能可以让软件在开发和维护时，达到充分的延伸性
通俗理解:让具有继承关系的不同类对象，可以对相同名称的成员函数调用，产生不同的反应结果

权限控制

RBAC（Role-Based Access Control）

基于角色的访问控制系统

• 用户表
• 权限表
• 角色表
• 角色权限表
• 用户角色表

ACL（Access Control List）

访问控制列表，是前几年盛行的一种权限设计，它的核心在于用户直接和权限挂钩

RBAC的核心是用户只和角色关联，而角色代表对了权限，这样设计的优势在于使得对用户而言，只需角色即可以，而某角色可以拥有各种各样的权限并可继承
ACL和RBAC相比缺点在于由于用户和权限直接挂钩，导致在授予时的复杂性，虽然可以利用组来简化这个复杂性，但仍然会导致系统不好理解，而且在取出判断用户是否有该权限时比较的困难，一定程度上影响了效率

ACL实质上是每一个权限接口维持一个权限列表，然后通过判断是否在列表中这个扁平快的方法，进行基础的权限控制，也有其不足：对于多人控制的某些系统，权限需要分为select，update，insert，delete等，人员需要分为管理员，用户，访客，超级管理员，这种情况下再使用ACL反而是增加工作量，增加后期维护难度，同时增加管理难度

在这种情况下，RBAC应运而生RBAC，基于组的权限控制，ACL的升级版

相比于ACL，RBAC的优势是将角色和角色绑定，将用户与权限之间的关联变为权限与角色之间的关联，从而简化了权限管理。当然普通的RBAC也有自身的缺点，就是权限是以角色为载体，单独用户的特殊的权限需要定制

使用 OpCache 提升 PHP 5.5+ 程序性能

what

PHP 5.5 以后内建了 OpCache , OpCache 的加速原理是把编译后的 bytecode 存储在内存里面, 避免重复编译 PHP 所造成的资源浪费.

how

修改 php.ini 文件,在文件最后面加入:

1
2
3
4
5
6
7
8
9
10
11

; 开关打开
opcache.enable=1
; 可用内存, 酌情而定, 单位 megabytes
opcache.memory_consumption=256
; 对多缓存文件限制, 命中率不到 100% 的话, 可以试着提高这个值
opcache.max_accelerated_files=5000
; Opcache 会在一定时间内去检查文件的修改时间, 这里设置检查的时间周期, 默认为 2, 定位为秒
opcache.revalidate_freq=240

APC VS OpCache

APC 是将要被遗弃的项目, PHP 5.5 都不支持, 而在 PHP 5.5 和 5.6 版本, OpCache 是默认内建的, 并且支持 5.2 到 5.4 的安装.

关于composer.lock

composer.lock

什么是 composer.lock 文件?

composer.lock 文件是当你第一次使用 composer install 或者 执行 composer update 后生成的文件, 此文件里定义了当前项目的代码依赖, 还有最重要的, 这些代码依赖的对应的版本.

composer.lock 文件作用是什么?

默认情况下, 当执行 composer install 的时候, Composer 会检查当前项目是否有 composer.lock 文件, 如果有的话, 就会按照此文件去下载代码依赖和其指定的版本.

把 composer.lock 文件加版本的好处有以下:

团队开发的时, clone 下代码后, 使用 composer install 可以确保大家使用的依赖包都是同一个版本的, 避免没必要的混乱;
在一个现有的项目上开发的时候, 执行 composer update 后, 偶尔会发现刚刚更新了某个代码包把程序整挂了, 这个时候, 如果 composer.lock 是加入版本控制器的话, 直接一个 git diff 命令, 就可以查看到这次更新了那个包, 快速定位到问题的所在;
在线上部署的时候, 可以确保线上生成环境下使用所有代码是和开发时候使用的一致, 因为 composer.lock 会确保你在执行 composer install 命令后, 按照文件里面指定的版本去下载代码依赖包;

php自身的性能优化

• OPcache
• 通过 PHP 扩展代替原 PHP 代码中高频逻辑
• Runtime优化:HHVM

php周边问题

• linux 运行环境
• 文件存储
• 数据库
• 缓存
• 网络

Disk IO优化

RAID0: 也称为条带，就是把多个磁盘链接成一个硬盘使用，这个级别IO最好
RAID1: 也称为镜像，要求至少有两个磁盘，每组磁盘存储的数据相同
RAID5: 也是把多个（最少3个）硬盘合并成1个逻辑盘使用，数据读写时建立就效验信息，并且奇偶效验信息和相对应的数据分别存储于不同的磁盘上。当RAID5的一个磁盘数据发生损坏后，利用剩下的数据和响应的奇偶效验信息去恢复被损坏的数据
RAID1+0: 就是RAID1和RAID0的结合。同时具备两个级别的优缺点。一般建议数据库使用这个级别

PHP文件执行阶段

语法分析->编译->运行

配置与设计模式

1. PHP中使用ArrayAccess实现配置文件的加载
2. 在工厂方法中读取配置，生成可配置化的对象
3. 使用装饰器模式实现权限验证，模板渲染，JSON串化
4. 使用观察者模式实现数据更新事件的一系列更新操作
5. 使用代理模式实现数据库的主从自动切换

MVC

• 模型: 数据和存储的封装
• 视图: 展示层的封装，如Web系统中的模板文件
• 控制器: 逻辑层的封装