php的设计模式
Posted myvic
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了php的设计模式相关的知识,希望对你有一定的参考价值。
1.单一职责原则
单一职责原则(Single Responsibility Principle)
含义:1.避免相同的职责分散到不同的类中,2.避免一个类承担太多的职责;
srp的好处:
减少类之间的耦合度
提高类的复用性
实际使用:
- 根据业务流程将业务对象抽离出来
- 注意职责的分类
单一职责原则的思想不仅应用于类中,在类的方法中,也应该有很好的体现;
也就是一个方法的逻辑不能过于复杂,而应该将不同的逻辑分离出来,最终简化方法的功能,提高代码的可读性;
例如,用户提交一个请求,我们需要对其参数进行简单的验证,那么这个验证的逻辑就可以分离出几个不同的方法来单独处理:
2.接口隔离原则
接口隔离原则(Interface Segregation Principle ,缩写:ISP),客户端不应该依赖它不需要的接口;一个类对另一个类的依赖应该建立在最小的接口上。
使用多个专门的接口比使用单一的总接口要好。
一个类对另外一个类的依赖性应当是建立在最小的接口上的。
一个接口代表一个角色,不应当将不同的角色都交给一个接口。没有关系的接口合并在一起,形成一个臃肿的大接口,这是对角色和接口的污染。
“不应该强迫客户依赖于它们不用的方法。接口属于客户,不属于它所在的类层次结构。”;再通俗点讲,不要强迫客户使用她们不用的方法,如果强迫用户使用她们不使用的方法,那么这些客户就会面临由于这些不使用的方法的改变所带来的改变。
3.开放-封闭原则
开闭原则(Open Close Principle,缩写:OCP),软件中的对象(类、模块、函数等)应该对于扩展是“开放”的,但是对于修改是“封闭”的。通俗点讲就是软件系统中包含的各种组件应该在不修改现有代码的基础上引入新功能。“开”是对于组件功能的扩展是开放的,
是允许对其进行功能扩展的;“闭”是对于原有代码的修改是封闭的,即不应该修改原有代码。
特征:
让程序更稳定、更灵活:
1.对于扩展是开放的:当应用的需求改变时,我们可以对模块进行扩展,使其具有满足那些改变的新行为。也就是说,我们可以改变模块的功能。
2.对于修改是封闭的:对模块行为进行扩展时,不必改动模块的源代码或者二进制码。
4.替换原则
里氏替换原则(Liskov Substitution Principle ,缩写:LSP),原则说任何基类可以出现的地方,子类一定可以出现。LSP是继承复用的基石,只有当衍生类可以替换掉基类,软件单位的功能不受到影响时,基类才能真正被复用,而衍生类也能在基类的基础上增加新的行为。
里氏替换原则的核心原理是抽象,抽象又依赖于继承这个特性,在OOP中,继承的优缺点相当明显,主要有以下几点
优点:1.代码重用,减少创建类的成本,每个子类都拥有父类的方法和属性;2.子类与父类基本相似,但又与父类有所区别;3.提高代码的可扩展性。
缺点:1.继承是侵入性的,只要继承就必须拥有父类的所有属性和方法;2.可能造成子类代码冗余、灵活性降低,因为子类必须拥有父类的属性和方法。
LSP:它主要是针对继承的设计原则
5.依赖倒置原则
依赖倒置原则(Dependence Inversion Principle ,缩写:DIP),是程序要依赖于抽象接口,不要依赖于具体实现。简单的说就是要求对抽象进行编程,不要对实现进行编程,这样就降低了客户与实现模块间的耦合。 原则 1.高层次的模块不应该依赖于低层次的模块,他们都应该依赖于抽象。上层模块不应该依赖于下层模块,他们共同依赖于一个抽象(父类不能依赖于子类,他们都要依赖于抽象类) 2.抽象不应该依赖于具体实现,具体实现应该依赖于抽象。
6.最少知识原则
迪米特原则(Law of Demeter ,缩写:LoD),又叫作最少知识原则(Least Knowledge Principle,简写LKP),就是说一个对象应当对其他对象有尽可能少的了解。
原则
一个类应该对自己需要耦合或调用的类知道的最少,类的内部如何实现与调用者或者依赖者没关系,调用者或者依赖者只需要知道它需要的方法即可,其他的可一概不用管。类与类之间的关系越密切,耦合度越大,当一个类发生改变时,对另一个类的影响也越大。
迪米特法则可以简单说成:talk only to your immediate friends.也就是“只与直接的朋友通信”。至于什么是直接的朋友?每个对象都必然会与其它对象有耦合关系,两个对象之间的耦合就成为朋友关系,这种关系的类型有很多,如组合、聚合、依赖等
以上是关于php的设计模式的主要内容,如果未能解决你的问题,请参考以下文章