PHP设计原则
Laravel
- PHP设计模式
定义：将PHP设计成一个固化的模式
- 面向对象设计原则
内聚度：高内聚，表示一个应用程序的单个单元所负责的任务数量和多样性。内聚与单个类或者单个方法单元相关
耦合度：低耦合。耦合度表示类之间关系的紧密程度。
耦合度决定了变更一个应用程序的容易程度。在紧密耦合度的类结构当中，更改一个类会导致其他的类也随之需要做出修改。显然，这是我们在类设计时应该避免的，因为微小的修改会迅速波动影响到整个应用程序。此外，找到需要修改的所有地方是必须的，实际上就是使得修改变得困难并且耗费时间而在松散耦合的系统中，我们可以更改一个类，不需要修改其他类，而应用程序仍然能够正常工作。
如何衡量软件设计质量：
满足软件的功能需求
满足软件功能需求设计并不一定就是好的设计
好的设计：
可读性：软件的设计文档是否轻易被其他程序员理解。可读性差的设计会给大型软件的开发和维护过程带来严重的危害
可复用性：软件系统的架构、类、组件等单元能否很容易被本项目的其他部分或者其他项目复用
可扩展性：软件面对需求变化时，功能或性能扩展的难易程度。
可维护性：软件维护（主要是指软件错误的修改，遗漏功能的添加等）的难易程度。
- 设计原则
|
设计原则名称 |
设计原则概念 |
重要性 |
|
单一职责原则 |
类的职责要单一，不能将太多的职责放在一个类中 |
☆☆☆☆ |
|
开闭原则 |
软件实体对扩展是开放的，但对修改是关闭的，即在不修改一个软件实体的基础上去扩展其功能 |
☆☆☆☆☆ |
|
里氏替换原则 |
在软件系统中，一个可以接受基类对象的地方必然可以接受一个子类对象 |
☆☆☆☆ |
|
依赖倒转原则 |
要针对抽象层编程，而不要针对具体类编程 |
☆☆☆☆☆ |
|
接口隔离原则 |
使用多个专门的接口来取代一个统一的接口 |
☆☆ |
|
组合/聚合复用原则 |
在系统中应该尽量使用组合和聚合关联关系，尽量少使用甚至不使用继承关系 |
☆☆☆☆ |
|
迪米特法则 |
一个软件实体对其他实体的引用越少越好，或者说如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用，而是通过引入一个第三者发生间接交互 |
☆☆☆ |
（1）单一职责：定义：所有的对象都应该有单一的职责，它提供的所有的服务也都仅围绕着这个职责。
换一句话说，一个类而言，应该仅有一个引起它变化的原因，永远不要让一个类存在多个改变的理由。
（2）里氏替换原则：在一个软件系统中，子类应该能够完全替换任何父类能够出现的地方，并且经过替换后，不会让调用父类的客户程序从行为上有任何改变。
里氏替换原则是使代码符合开闭原则的一个重要的保证，同时，它体现了：
类的继承原则：里氏替换原则常用来检查两个类是否为继承关系。在符合里氏替换原则的继承关系中，使用父类代码的地方，用子类代码替换后，能够正确的执行动作处理。换句话说，如果子类替换了父类后，不能够正确执行动作，那么他们的继承关系就是不正确的，应该重新设计它们之间的关系。
动作正确性保证：里氏替换原则对子类进行了约束，所以在为已存在的类进行扩展，来创建一个新的子类时，符合里氏替换原则的扩展不会给已有的系统引入新的错误。
DI：Dependency Injection 依赖注入
IOC:Inversion of Control 控制反转
（4）依赖倒转原则：
依赖倒转原则（Dependency Inversion Principle，简称DIP）是指将两个模块之间的依赖关系倒置为依赖抽象类或接口。具体有两层含义：
高层模块不应该依赖于低层模块，二者都应该依赖于抽象；
抽象不应该依赖于细节，细节应该依赖于抽象。
在面向对象设计中，类和类之间依赖关系可以分为两种类型：
具体耦合关系：发生在两个具体的（可实例化的）类之间，经由一个类对另一个具体类的直接引用造成。
抽象耦合关系：发生在一个具体类和一个抽象类（或接口）之间，使两个必须发生关系的类之间存有最大的灵活性。
（5）组合/聚合复用原则
组合/聚合复用原则（Composite/Aggregation Reuse Principle，CARP）是指要尽量使用组合/聚合而非继承来达到复用目的。另一种解释是在一个新的对象中使用一些已有的对象，使之成为新对象的一部分；新的对象通过向这些对象委托功能达到复用这些对象的目的。
（6）接口隔离原则
接口隔离原则（Interface Segregation Principle，简称ISP）是指客户不应该依赖它们用不到的方法，只给每个客户它所需要的接口。换句话说，就是不能强迫用户去依赖那些他们不使用的接口。
