PHP设计原则

Laravel

 

1. PHP设计模式

　　定义：将PHP设计成一个固化的模式

1. 面向对象设计原则

内聚度：高内聚，表示一个应用程序的单个单元所负责的任务数量和多样性。内聚与单个类或者单个方法单元相关

耦合度：低耦合。耦合度表示类之间关系的紧密程度。

耦合度决定了变更一个应用程序的容易程度。在紧密耦合度的类结构当中，更改一个类会导致其他的类也随之需要做出修改。显然，这是我们在类设计时应该避免的，因为微小的修改会迅速波动影响到整个应用程序。此外，找到需要修改的所有地方是必须的，实际上就是使得修改变得困难并且耗费时间而在松散耦合的系统中，我们可以更改一个类，不需要修改其他类，而应用程序仍然能够正常工作。

如何衡量软件设计质量：

满足软件的功能需求

满足软件功能需求设计并不一定就是好的设计

好的设计：

可读性：软件的设计文档是否轻易被其他程序员理解。可读性差的设计会给大型软件的开发和维护过程带来严重的危害

可复用性：软件系统的架构、类、组件等单元能否很容易被本项目的其他部分或者其他项目复用

可扩展性：软件面对需求变化时，功能或性能扩展的难易程度。

可维护性：软件维护（主要是指软件错误的修改，遗漏功能的添加等）的难易程度。

1. 设计原则

设计原则名称	设计原则概念	重要性
单一职责原则	类的职责要单一，不能将太多的职责放在一个类中	☆☆☆☆
开闭原则	软件实体对扩展是开放的，但对修改是关闭的，即在不修改一个软件实体的基础上去扩展其功能	☆☆☆☆☆
里氏替换原则	在软件系统中，一个可以接受基类对象的地方必然可以接受一个子类对象	☆☆☆☆
依赖倒转原则	要针对抽象层编程，而不要针对具体类编程	☆☆☆☆☆
接口隔离原则	使用多个专门的接口来取代一个统一的接口	☆☆
组合/聚合复用原则	在系统中应该尽量使用组合和聚合关联关系，尽量少使用甚至不使用继承关系	☆☆☆☆
迪米特法则	一个软件实体对其他实体的引用越少越好，或者说如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用，而是通过引入一个第三者发生间接交互	☆☆☆

（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）是指客户不应该依赖它们用不到的方法，只给每个客户它所需要的接口。换句话说，就是不能强迫用户去依赖那些他们不使用的接口。