PHP面向对象五大原则之依赖倒置原则(DIP)详解

本文实例讲述了PHP面向对象五大原则之依赖倒置原则(DIP)。分享给大家供大家参考，具体如下：

什么是依赖倒置呢？简单地讲就是将依赖关系倒置为依赖接口，具体概念如下：

1.上层模块不应该依赖于下层模块，它们共同依赖于一个抽象（父类不能依赖子类，它们都要依赖于抽象类）

2.抽象不能依赖于具体，具体应该要依赖于抽象。

注意，这里的接口不是狭义的接口。

为什么要依赖接口？因为接口体现对问题的抽象，同时由于抽象一般是相对稳定的或者是相对变化不频繁的，而具体是易变的。因此依赖抽象是实现代码扩展和运行期内绑定（多态）的基础：只要实现了该抽象类的子类，都可以被类的使用都使用。这里，强调一下扩展性这个概念。通常扩展性指对已知行为的扩展，在讲述接口时，也提到过，接口应该是相对的。这就告诉我们，无论使用多么先进的设计模式，也无法做到不需要修改代码即可达到不变应万变的地上。在面向对象的这五大原则里，我认为依赖倒置是最难理解，也是最难实现的。

这里以雇员类为例

<?php
interface employee
{
  public function working();
}
class teacher implements employee
{
  public function working()
  {
    echo 'teaching...';
  }
}
class coder implements employee
{
  public function working()
  {
    echo 'coding...';
  }
}
class workA
{
  public function work()
  {
    $teacher = new teacher();
    $teacher->working();
  }
}
class workB
{
  private $e;
  public function set(employee $e)
  {
    $this->e = $e;
  }
  public function work()
  {
    $this->e->working();
  }
}
$worka = new workA;
$worka->work();
$workb = new workB;
$workb->set(new teacher());
$workb->work();

在workA中，work方法依赖于teacher实现；在workB中，work转而依赖抽象，这样可以把需要的对象通过参数传入。上述代码通过接口，实现了一定程度的解耦，但仍然是有限的。不仅是使用接口，使用工厂等也能实现一定程度的解耦和依赖倒置。

在workB中，teacher实例通过set方法传入，从而实现了工厂模式。由于这样的实现仍然是硬编码的，为了实现代码的进一步扩展，把这个依赖关系写在配置文件里，指明workB需要一个teacher对象，专门由一个程序配置是否正确（如所依赖的类文件是否存在）以及加载配置中所依赖的实现，这个检测程序，就称为IOC容器。

很多文章里看到IOC（Inversion of Control）概念，实际上，IOC是依赖倒置原则（Dependence Inversion Principle，DIP）的同义词。而在提IOC的时候，你可能还会看到有人提起DI等概念。DI，即依赖注入，一般认为，依赖注入（DI）和依赖查找（DS）是IOC的两种实现。不过随着某些概论的演化，这几个概念之间的关系也变得很模糊，也有人认为IOC就是DI。有人认为，依赖注入的描述比起IOC来更贴切，这里不纠缠于这几个概念之间的关系。

在经典的J2EE设计里，通常把DAO层和Servicen层细分为接口层和实现层，然后在配置文件里进行所依赖关系的配置，这是最常见的DIP的应用。Spring框架就是一个很好的IOC容器，把控制权从代码剥离到IOC窗口，这里是通过XML配置文件实现的，Spring在执行期间根据配置文件的设定，建立对象之间的依赖关系。

如下面的代码所示

<bean scopre="prototype" class="cn.notebook.action.NotebookListOtherAction" id="notebookListOtherAction">
  <property ref="userReplyService" name="userReplyService" />
  <property ref="userService" name="userService" />
  <property ref="permissionService" name="permissionService" />
  <property ref="friendService" name="friendService" />
</bean>

但是这样的设置一样存在问题，配置文件会变得越来越大，其间关系会越来越复杂。同样逃脱不了随着应用和业务的改变，不断修改代码的恶魇（这里认为配置文件是代码的一部分。并且在实际开发中，很少存在单纯修改配置文件的情况。一般配置文件修改了，代码也会做相应的修改）

在PHP里，也有类似模仿Spring的实现，即把依赖关系写在了配置文件里，通过配置文件来产生需要的对象。我觉得这样的代码还是为了实现而实现。在Srping里，配置文件里配置的不仅仅是一个类运行时的依赖关系，还可以实现事务管理、AOP、延迟加载等。而PHP要实现上面的种种特性，其消耗是巨大的。从语言层面讲，PHP这种动态脚本语言在实现一些多态特性上和编译型的语言不同。其次PHP作为敏捷性的开发语言，更强调快速开发、逻辑清晰、代码更简单易懂，如果再附加了各种设计模式的框架，从技术实现和运行效率上来看，都是不可取的。依赖倒置的核心原则是解耦。如果脱离这个最原始的原则，那就是本末倒置。

事实上，很多的设计模式里已经隐含了依赖倒置原则我们也在有意无意地做着一些依赖反转的工作。只是作为PHP，目前还没有一个比较完善的IOC容器，或许是PHP根本不需要。

如果满足DIP：

1.每个较高层次类都为它所需要的服务提出一个接口声明，较低层次类实现实现这个接口。

2.每个高层次类都通过该抽象接口使用服务。

更多关于PHP相关内容感兴趣的读者可查看本站专题：《php面向对象程序设计入门教程》、《PHP数组(Array)操作技巧大全》、《PHP基本语法入门教程》、《PHP运算与运算符用法总结》、《php字符串(string)用法总结》、《php+mysql数据库操作入门教程》及《php常见数据库操作技巧汇总》

希望本文所述对大家PHP程序设计有所帮助。

您可能感兴趣的文章:

  • PHP面向对象五大原则之里氏替换原则(LSP)详解
  • 举例解析Java的设计模式编程中里氏替换原则的意义
  • 详解Java设计模式编程中的里氏替换原则
  • 深入理解JavaScript系列(8) S.O.L.I.D五大原则之里氏替换原则LSP
  • PHP面向对象五大原则之接口隔离原则(ISP)详解
  • PHP面向对象五大原则之开放-封闭原则(OCP)详解
  • PHP面向对象五大原则之单一职责原则(SRP)详解
  • PHP基于面向对象实现的留言本功能实例
  • PHP面向对象之里氏替换原则简单示例
赞 (0)

相关推荐

  • PHP面向对象五大原则之里氏替换原则(LSP)详解

    本文实例讲述了PHP面向对象五大原则之里氏替换原则(LSP).分享给大家供大家参考,具体如下: 替换原则由MIT计算机科学实验室的Liskov女士在1987年的OOPSLA大会上的一篇文章中提出,主要阐述有关继承的一些原则,故称里氏替换原则. 2002年,Robert C.Martin出版了一本名为<Agile Software Development Principles Patterns and Practices>的书,在书中他把里氏替换原则最终简化成一句话:"Subtypes

  • 详解Java设计模式编程中的里氏替换原则

    定义1:如果对每一个类型为 T1的对象 o1,都有类型为 T2 的对象o2,使得以 T1定义的所有程序 P 在所有的对象 o1 都代换成 o2 时,程序 P 的行为没有发生变化,那么类型 T2 是类型 T1 的子类型. 定义2:所有引用基类的地方必须能透明地使用其子类的对象. 问题由来:有一功能P1,由类A完成.现需要将功能P1进行扩展,扩展后的功能为P,其中P由原有功能P1与新功能P2组成.新功能P由类A的子类B来完成,则子类B在完成新功能P2的同时,有可能会导致原有功能P1发生故障. 解决方

  • 深入理解JavaScript系列(8) S.O.L.I.D五大原则之里氏替换原则LSP

    前言 本章我们要讲解的是S.O.L.I.D五大原则JavaScript语言实现的第3篇,里氏替换原则LSP(The Liskov Substitution Principle ). 英文原文:http://freshbrewedcode.com/derekgreer/2011/12/31/solid-javascript-the-liskov-substitution-principle/ 复制代码 开闭原则的描述是: Subtypes must be substitutable for the

  • PHP基于面向对象实现的留言本功能实例

    PHP基于面向对象实现的留言本功能实例

    本文实例讲述了PHP基于面向对象实现的留言本功能.分享给大家供大家参考,具体如下: 要设计一留言本,一切都将以留言本为核心,抓到什么是什么,按流程走下来,即按用户填写信息->留言->展示的流程进行. 现在用面向对象的思维思考这个问题,在面向对象的世界,会想尽办法把肉眼能看见的以及看不见的,但是实际存在的物或者流程抽象出来.既然是留言本,那么就存在留言内容这个实体,这个留言实体(domain)应该包括留言者姓名.E-mail.留言内容等要素,如下面代码所示 //留言实体类 class messa

  • PHP面向对象五大原则之单一职责原则(SRP)详解

    本文实例讲述了PHP面向对象五大原则之单一职责原则(SRP).分享给大家供大家参考,具体如下: 单一职责原则(Single Pesponsibility Principle, SRP) 单一职责有两个含义: 一个是避免相同的职责分散到不同的类中, 别一个是避免一个类承担太多职责 为什么要遵守SRP呢? (1)可以减少类之间的耦合 如果减少类之间的耦合,当需求变化时,只修改一个类,从而也就隔离了变化:如果一个类有多个不同职责,它们耦合在一起,当一个职责发生变化时,可能会影响到其他职责. (2)提高

  • 举例解析Java的设计模式编程中里氏替换原则的意义

    里氏替换原则,OCP作为OO的高层原则,主张使用"抽象(Abstraction)"和"多态(Polymorphism)"将设计中的静态结构改为动态结构,维持设计的封闭性."抽象"是语言提供的功能."多态"由继承语义实现. 里氏替换原则包含以下4层含义: 子类可以实现父类的抽象方法,但是不能覆盖父类的非抽象方法. 子类中可以增加自己特有的方法. 当子类覆盖或实现父类的方法时,方法的前置条件(即方法的形参)要比父类方法的输入参数更

  • PHP面向对象五大原则之接口隔离原则(ISP)详解

    本文实例讲述了PHP面向对象五大原则之接口隔离原则(ISP).分享给大家供大家参考,具体如下: 设计应用程序的时候,如果一个模块包含多个子模块,那么我们应该小心对模块做出抽象.设想该模块由一个类实现,我们可以把系统抽象成一个接口.但是要添加一个新的模块扩展程序时,如果要添加的模块只包含原系统中的一些子模块,那么系统就会强迫我们实现接口中的所有方法,并且清寒要编写一些哑方法.这样的接口被称为肚胖接口或者被污染的接口,使用这样的接口将会给系统引入一些不当的行为,这些不当的行为可能导致不正确的结果,也

  • PHP面向对象五大原则之开放-封闭原则(OCP)详解

    本文实例讲述了PHP面向对象五大原则之开放-封闭原则(OCP).分享给大家供大家参考,具体如下: 1. 什么是"开放-封闭" 随着软件系统规模的不断增大,软件系统的维护和修改的复杂性不断提高,这种困境促使法国工程院士Bertrand Meyer在1998年提出了"开放-封闭"(Open-Close Principle,OCP)原则,这条原则的基本思想是: Open(Open for extendtion)模块的行为必须是开放的.支持扩展的,而不是僵化的. Close

  • PHP面向对象之里氏替换原则简单示例

    本文实例讲述了PHP面向对象之里氏替换原则.分享给大家供大家参考,具体如下: 里氏替换原则(Liskov Substitution Principle) 里氏替换原则告诉我们,在软件中将一个基类对象替换成它的子类对象,程序将不会产生任何错误和异常,反过来则不成立,如果一个软件实体使用的是一个子类对象的话,那么它不一定能够使用基类对象.里氏替换原则是实现开闭原则的重要方式之一,由于使用基类对象的地方都可以使用子类对象,因此在程序中尽量使用基类类型来对对象进行定义,而在运行时再确定其子类类型,用子类

  • PHP面向对象五大原则之依赖倒置原则(DIP)详解

    本文实例讲述了PHP面向对象五大原则之依赖倒置原则(DIP).分享给大家供大家参考,具体如下: 什么是依赖倒置呢?简单地讲就是将依赖关系倒置为依赖接口,具体概念如下: 1.上层模块不应该依赖于下层模块,它们共同依赖于一个抽象(父类不能依赖子类,它们都要依赖于抽象类) 2.抽象不能依赖于具体,具体应该要依赖于抽象. 注意,这里的接口不是狭义的接口. 为什么要依赖接口?因为接口体现对问题的抽象,同时由于抽象一般是相对稳定的或者是相对变化不频繁的,而具体是易变的.因此依赖抽象是实现代码扩展和运行期内绑

  • Java设计模式七大原则之依赖倒置原则详解

    目录 定义 案例 需求 方案一 方案二 对比分析 总结 定义 依赖倒转原则,又称依赖倒置原则(Dependence Inversion Principle),又称DIP原则,即:上层模块不应该依赖底层模块,它们都应该依赖于抽象,抽象不应该依赖于细节,细节应该依赖于抽象.抽象对代码来说即接口或者抽象类 细节对代码来说即实现类.换句话说 依赖倒转原则的核心的理念 相对于细节来说,抽象要稳定得多.要求我们 面向接口编程,进行设计. 案例 需求 工作人员接收微信老板发来的加班消息 方案一 定义工作人员W

  • C#实现六大设计原则之依赖倒置原则

    C#实现六大设计原则之依赖倒置原则

    依赖倒置原则(DIP)定义: 高层模块不应该依赖低层模块,二者都应该依赖其抽象:抽象不应该依赖细节:细节应该依赖抽象. 问题由来: 类A直接依赖类B,假如要将类A改为依赖类C,则必须通过修改类A的代码来达成.这种场景下,类A一般是高层模块, 负责复杂的业务逻辑:类B和类C是低层模块,负责基本的原子操作:假如修改类A,会给程序带来不必要的风险. 解决方案: 将类A修改为依赖接口I,类B和类C各自实现接口I,类A通过接口I间接与类B或者类C发生联系,则会大大降低修改类A的几率. ps: 依赖倒置原则

  • 深入理解JavaScript系列（22）：S.O.L.I.D五大原则之依赖倒置原则DIP详解

    前言 本章我们要讲解的是S.O.L.I.D五大原则JavaScript语言实现的第5篇,依赖倒置原则LSP(The Dependency Inversion Principle ). 英文原文:http://freshbrewedcode.com/derekgreer/2012/01/22/solid-javascript-the-dependency-inversion-principle/ 依赖倒置原则 依赖倒置原则的描述是: A. High-level modules should not

  • java面向对象设计原则之单一职责与依赖倒置原则详解

    目录 单一职责概念 实现 拓展 依赖倒置原则概念 示例 拓展 单一职责概念 不要存在多于一个导致类变更的原因,也就是说每个类应该实现单一的职责,否则就应该把类拆分.交杂不清的职责将使得代码牵一发而动全身,导致代码混涩难懂,不易修改.难以扩展和复用.如:以前开发C/S程序中的胖客户端程序,就是将人机交互逻辑.业务加工处理逻辑和数据库操作逻辑混合在一起. 实现 单一职责原则是进行类的划分和封装的基本原则,进行类的具体抽象.尽量做到,类的功能单一和清晰化. 1.根据机能划分,使用封装来创建对象之间的分

  • 详解Java设计模式编程中的依赖倒置原则

    定义: 高层模块不应该依赖低层模块,二者都应该依赖其抽象:抽象不应该依赖细节:细节应该依赖抽象. 问题由来:类A直接依赖类B,假如要将类A改为依赖类C,则必须通过修改类A的代码来达成.这种场景下,类A一般是高层模块,负责复杂的业务逻辑:类B和类C是低层模块,负责基本的原子操作:假如修改类A,会给程序带来不必要的风险. 解决方案:将类A修改为依赖接口I,类B和类C各自实现接口I,类A通过接口I间接与类B或者类C发生联系,则会大大降低修改类A的几率.          依赖倒置原则基于这样一个事实:

  • 深入浅析python3 依赖倒置原则(示例代码)

    场景 针对园区停车信息,需要对各个公司提供的停车数据进行整合并录入自家公司的大数据平台 数据的录入无外乎就是对数据的增删改查 下面上一个常规的写法(未符合依赖倒置),整合来自 长安和丰田 的停车数据 class Changan(object): def __init__(self): self.type = 'changan' def ca_add(self): print('%s 新增' % self.type) def ca_del(self): print('%s 删除' % self.t

  • java的依赖倒置原则你了解多少

    java的依赖倒置原则你了解多少

    目录 依赖倒置原则 案例: 背景: 1.面向实现编程 2.面向接口编程(简单版) 总结 依赖倒置原则 什么是依赖倒置原则: 高层模块不应该依赖低层模块,二者都应该依赖其抽象 抽象不应该依赖细节,细节应该依赖抽象 针对接口编程,不要针对实现编程 即: 每个类尽量继承自接口或者抽象类 优点:减少类之间的耦合,提高代码的稳定性,代码的可读性维护性. 案例: 背景: 现在有一个用户类叫Ggzx(也就是我),想要学习一些课程,简单的来实现调用学习的方法,然后在一个Test类之中输入学习的内容.但是我暂时只

  • C#编程之依赖倒置原则DIP

    C#编程之依赖倒置原则DIP

    一.前言 我们先来看看传统的三层架构,如下图所示: 从上图中我们可以看到:在传统的三层架构中,层与层之间是相互依赖的,UI层依赖于BLL层,BLL层依赖于DAL层.分层的目的是为了实现“高内聚.低耦合”.传统的三层架构只有高内聚没有低耦合,层与层之间是一种强依赖的关系,这也是传统三层架构的一种缺点.这种自上而下的依赖关系会导致级联修改,如果低层发生变化,可能上面所有的层都需要去修改,而且这种传统的三层架构也很难实现团队的协同开发,因为上层功能取决于下层功能的实现,下面功能如果没有开发完成,则上层

  • java面向对象设计原则之迪米特法则分析详解

    目录 概念 使用 拓展 概念 迪米特法则解决类与类之间耦合度问题,如果类A调用了B类的某一个方法,则这两个类就形成了一种紧耦合的方式,当B类这个方法发生变化时,一定会影响A类的执行结果.迪米特法则要求每一个类尽可能少的与其他类发生关系,也就是尽可能少的让其他类发生变化时,对其代码的执行结果产生的影响降到最低. 典型情况:A类调用B类的方法,B类和C类是一种关联关系,如果A类通过B类所持有的C类对象直接调用C类的方法,则A类和C类同时拥有强耦合的关系.代码如下: public class B {

随机推荐