设计模式提供了一种广泛的可重用的方式来解决我们日常编程中常常遇见的问题
它并不是一个类库或者第三方框架，更多的表现为一种思想，并且广泛地应用在系统中
它们也表现为一种模式或者模板，可以在多个不同的场景下用于解决问题
设计模式可以用于加速开发，并且将很多大的想法或者设计以一种简单地方式实现。当然，虽然设计模式在开发中很有作用，但是千万要避免在不适当的场景误用它们。
目前 PHP 的设计模式主要有 23 种，根据使用目标的不同可以分为以下三大类：
- 创建模式（Creational Patterns）：用于创建对象从而将某个对象从实现中解耦合。
- 架构模式（Structural Patterns）：用于在不同的对象之间构造大的对象结构。
- 行为模式（Behavioral Patterns）：用于在不同的对象之间管理算法、关系以及职责。
设计模式六大原则
SOLID 是 Michael Feathers 推荐的便于记忆的首字母简写，它代表了 Robert Martin 命名的最重要的五个面对对象编码设计原则：
职责单一原则（SRP）
Single Responsibility Principle
一个类只负责一件事。
开闭原则（OCP）
Open/Closed Principle
一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。
你应该允许在不改变已有代码的情况下增加新的功能。
里氏替换原则（LSP）
Liskov Substitution Principle
这是一个简单的原则，却用了一个不好理解的术语。
对这个概念最好的解释是：如果你有一个父类和一个子类，在不改变原有结果正确性的前提下父类和子类可以互换。
接口隔离原则（ISP）
Interface Segregation Principle
调用方不应该被强制依赖于他不需要的接口。
当一个类需要一个大量的设置项，为了方便不会要求调用方去设置大量的选项，因为在通常他们不需要所有的设置项。使设置项可选有助于我们避免产生”胖接口”
依赖反转原则（DIP）
Dependency Inversion Principle
这条原则说明两个基本的要点：
- 高阶的模块不应该依赖低阶的模块，它们都应该依赖于抽象
- 抽象不应该依赖于实现，实现应该依赖于抽象
看起来有点晦涩难懂，但是如果你使用过框架（例如Symfony），你应该见过依赖注入（DI）对这个概念的实现。虽然它们不是完全相通的概念，依赖倒置原则使高阶模块与低阶模块的实现细节和创建分离。可以使用依赖注入（DI）这种方式来实现它。更多的好处是它使模块之间解耦。
在加上下面这条原则，构成设计模式六大原则
迪米特法则
Law of Demeter
又叫作最少知识原则（LKP，Least Knowledge Principle），一个对象应该对其他对象保持最少的了解。
重构
抽时间读了这本非常有名的书《重构–改善既有代码的设计》，结合一下网上大佬分享的思路，与自己平时的经验，写写小感悟
重构不是对以前代码的全盘否定，而是利用更好的方式，写出更好、更有维护性的代码
WHAT
首先，重构不是重写。重构大概的意思是在不影响项目的功能使用前提下，使用一系列的重构方式，改变项目的内部结构，提高项目内部的可读性，可维护性
无论是什么项目，都有一个从简单到复杂的一个迭代过程。在这个过程里面，在不影响项目的使用情况下，需要不断的对代码进行优化，保持或者增加代码的可读性，可维护性
这样一来，就可以避免在团队协作开发上需要大量的沟通才能加入项目的开发中
WHY
随着业务需求的不断增加，变更，舍弃，项目的代码也难免会出现瑕疵，这就会影响代码的可读性，可维护性，甚至影响项目的性能
而重构的目的，就是为了解决这些瑕疵，保证代码质量和性能
但是前提是不能影响项目的使用
至于重构的原因，自己总结了一下，大概有以下几点：
- 函数逻辑结构混乱，或因为没注释原因，连原代码写作者都很难理清当中的逻辑
- 函数无扩展性可言，遇到新的变化，不能灵活的处理
- 因为对象强耦合或者业务逻辑的原因，导致业务逻辑的代码巨大，维护的时候排查困难
- 重复代码太多，没有复用性
- 随着技术的发展，代码可能也需要使用新特性进行修改
- 随着学习的深入，对于以前的代码，是否有着更好的一个解决方案
- 因为代码的写法，虽然功能正常使用，但是性能消耗较多，需要换方案进行优化
WHEN
在我的理解中，重构可以说是贯穿整一个项目的开发和维护周期，可以当作重构就是开发的一部分
通俗讲，在开发的任何时候，只要看到代码有别扭，激发了强迫症，就可以考虑重构了
只是，重构之前先参考下面几点：
- 首先，重构是需要花时间去做的一件事。花的时间可能比之前的开发时间还要多
- 其次，重构是为了把代码优化，前提是不能影响项目的使用
- 最后，重构的难度大小不一，可能只是稍微改动，可能难度比之前开发还要难
基于上面的几点，需要大家去评估是否要进行重构
评估的指标，可以参考下面几点：
- 数量: 需要重构的代码是否过多
- 质量: 可读性，可维护性，代码逻辑复杂度，等问题，对代码的质量影响是否到了一个难以忍受的地步
- 时间: 是否有充裕的时间进行重构和测试
- 效果: 如果重构了代码，得到哪些改善，比如代码质量提高了，性能提升了，更好的支持后续功能等