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

本文实例讲述了PHP面向对象五大原则之单一职责原则(SRP)。分享给大家供大家参考,具体如下:

单一职责原则(Single Pesponsibility Principle, SRP)

单一职责有两个含义: 一个是避免相同的职责分散到不同的类中, 别一个是避免一个类承担太多职责

为什么要遵守SRP呢?

(1)可以减少类之间的耦合

如果减少类之间的耦合,当需求变化时,只修改一个类,从而也就隔离了变化;如果一个类有多个不同职责,它们耦合在一起,当一个职责发生变化时,可能会影响到其他职责。

(2)提高类的复用性

修改电脑比修理电视机简单多了。主要原因就在于电视机各个部件之间的耦合性太高,而电脑则不同,电脑的内存、硬盘、声卡、网卡、键盘灯等部件都可以很容易地单独拆卸和组装。某个部件坏了,换上新的即可。上面的例子就体现了单一职责的优势。由于使用了单一职责,使得‘组件'可以方便地‘拆卸'和‘组装'。

不遵守SRP会影响对类的复用性。当只需要用该类的某一个职责时,由于它和其他的职责耦合在一起,也就很难分离出。

遵守SRP在实际代码开发中有没有什么应用?有的。以数据持久层为例,所谓的数据持久层主要指的是数据库操作,当然,还包括缓存管理等。这时就需要数据持久层支持多种数据库。应该怎么做?定义多个数据库操作类?想法已经很接近了,再进一步,就是使用工厂模式。

工厂模式(Faction)允许你在代码执行时实例化对象。它之所以被称为工厂模式是因为它负责‘生产对象'。以数据库为例,工厂需要的就是根据不同的参数,生成不同的实例化对象。最简单的工厂就是根据传入的类型名实例化对象,如传入MySQL,就调用MySQL类并实例化,如果是SQLite,则调用 SQLite的类并实例化,甚至还可以处理TXT、Execl等‘类数据库'。

工厂类也就是这样的一个类,它只负责生产对象,而不负责对象的具体内容。

以下是示例

定义一个适配器的接口

interface Db_Adpater
{
  /**
   * 数据库连接
   * @param $config 数据库配置
   * @return mixed resource
   */
  public function connect($config);
  /**
   * 执行数据库查询
   * @param $query 数据库查询的SQL字符串
   * @param $handle 连接对象
   * @return mixed
   */
  public function query($query,$handle);
}

定义一个实现了DB_Adpater接口的MySQL数据库操作类

class Db_Adapter_Mysql implements Db_Adpater
{
  private $_dbLink;  //数据库连接字符串标识
  /**
   * 数据库连接函数
   * @param $config 数据库配置
   * @return resource
   * @throws Db_Exception
   */
  public function connect($config)
  {
    if($this->_dbLink = @mysql_connect($config->host . (empty($config->port) ? '' : ':' . $config->prot) ,$config->user, $config->password, true))
    {
      if(@mysql_select_db($config->database, $this->_dbLink))
      {
        if($config->charset)
        {
          mysql_query("SET NAME '{$config->charset}'", $this->_dbLink);
        }
        return $this->_dbLink;
      }
    }
    throw new Db_Exception(@mysql_error($this->_dbLink));
  }
  /**
   * 执行数据库查询
   * @param $query 数据库查询SQL字符串
   * @param $handle 连接对象
   * @return resource
   */
  public function query($query,$handle)
  {
    if($resource = @mysql_query($query,$handle))
      return $resource;
  }
}

定义一个实现了DB_Adpater接口的SQLite数据库操作类

class Db_Adapter_sqlite implements Db_Adpater
{
  private $_dbLink;  //数据库连接字符串标识
  public function connect($config)
  {
    if($this->_dbLink = sqlite_open($config->file, 0666, $error))
    {
      return $this->_dbLink;
    }
    throw new Db_Exception($error);
  }
  public function query($query, $handle)
  {
    if($resource = @sqlite_query($query,$handle))
    {
      return $resource;
    }
  }
}

现在如果需要一个数据库操作的方法怎么做,只需定义一个工厂类,根据传入不同的生成需要的类即可

class sqlFactory
{
  public static function factory($type)
  {
    if(include_once 'Drivers/' . $type . '.php')
    {
      $classname = 'Db_Adapter_'.$type;
      return new $classname;
    }
    else
      throw new Exception('Driver not found');
  }
}

调用时,就可以这么写

$db = sqlFactory::factory('MySQL');
$db = sqlFactory::factory('SQLite');

我们把创建数据库连接这块程序单独拿出来,程序中的CURD就不用关心什么数据库了,只要按照规范使用对应的方法即可。

工厂方法让具体的对象解脱出来,使其不再依赖具体的类,而是抽象。

设计模式里面的命令模式也是SRP的体现,命令模式分离“命令的请求者”和“命令的实现者”方面的职责。举一个很好理解的例子,就是你去餐馆订餐吃饭,餐馆存在顾客、服务员、厨师三个角色。作为顾客,你要列出菜单,传给服务员,由服务员通知厨师去实现。作为服务员,只需要调用准备饭菜这个方法(对厨师喊“该炒菜了”),厨师听到要炒菜的请求,就立即去做饭。在这里,命令的请求和实现就完成了解耦。

模拟这个过程,首先定义厨师角色,厨师进行实际做饭、烧汤的工作。

以下是示例

/**
 * 厨师类,命令接受者与执行者
 * Class cook
 */
class cook
{
  public function meal()
  {
    echo '番茄炒鸡蛋',PHP_EOL;
  }
  public function drink()
  {
    echo '紫菜蛋花汤',PHP_EOL;
  }
  public function ok()
  {
    echo '完毕',PHP_EOL;
  }
}
//然后是命令接口
interface Command
{
  public function execute();
}

轮到服务员出场,服务员是命令的传送者,通常你到饭馆吃饭都是叫服务员吧,不能直接叫厨师,一般都是叫“服务员,给我来盘番茄炒西红柿”。所以,服务员是顾客和厨师之间的命令沟通都。

class MealCommand implements Command
{
  private $cook;
  //绑定命令接受者
  public function __construct(cook $cook)
  {
    $this->cook = $cook;
  }
  public function execute()
  {
    $this->cook->meal();//把消息传给厨师,让厨师做饭,下同
  }
}
class DrinkCommand implements Command
{
  private $cook;
  //绑定命令接受者
  public function __construct(cook $cook)
  {
    $this->cook = $cook;
  }
  public function execute()
  {
    $this->cook->drink();
  }
}

现在顾客可以按照菜单叫服务员了

class cookControl
{
  private $mealcommand;
  private $drinkcommand;
  //将命令发送者绑定以命令接收器上面来
  public function addCommand(Command $mealcommand, Command $drinkcommand)
  {
    $this->mealcommand = $mealcommand;
    $this->drinkcommand = $drinkcommand;
  }
  public function callmeal()
  {
    $this->mealcommand->execute();
  }
  public function calldrink()
  {
    $this->drinkcommand->execute();
  }
}

好了,现在完成整个过程

$control = new cookControl;
$cook = new cook;
$mealcommand = new MealCommand($cook);
$drinkcommand = new DrinkCommand($cook);
$control->addCommand($mealcommand,$drinkcommand);
$control->callmeal();
$control->calldrink();

从上面的例子可以看出,原来设计模式并非纯理论的东西,而是来源于实际生活,就连普通的餐馆老板都懂设计模式这门看似高深的学问。其实,在经济和管理活动中对流程的优化就是对各种设计模式的摸索和实践。所以,设计模式并非计算机编程中的专利。事实上,设计模式的起源并不是计算机,而是源于建筑学。

在设计模式方面,不仅以上这两种体现了SRP,还有别的(比如代理模式)也体现了SRP。SRP不只是对类设计有意义,对以模块、子系统为单位的系统架构设计同样有意义。

模块、子系统也应该仅有一个引起它变化的原因,如MVC所倡导的各个层之间的相互分离就是SRP在系统总体设计中的应用。

SRP是最简单的原则之一,也是最难做好的原则之一。我们会很自然地将职责连接在一起。找到并且分离这些职责是软件设计需要达到的目的

一些简单的应用遵循的做法如下:

根据业务流程,把业务对象提炼出来。如果业务的流程的链路太复杂,就把这个业务对象分离为多个单一业务对象。当业务链标准化后,对业务对象的内部情况做进一步处理,把第一次标准化视为最高层抽象,第二次视为次高层抽象,以此类推,直到“恰如其分”的设计层次

职责的分类需要注意。有业务职责,还要有脱离业务的抽象职责,从认识业务到抽象算法是一个层层递进的过程。就好比命令模式中的顾客,服务员和厨师的职责,作为老板(即设计师)的你需要规划好各自的职责范围,即要防止越俎代庖,也要防止互相推诿。

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

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

您可能感兴趣的文章:

  • 简单理解遵循接口隔离原则的Java设计模式编程
  • 深入理解JavaScript系列(21):S.O.L.I.D五大原则之接口隔离原则ISP详解
  • 举例说明Java设计模式编程中ISP接口隔离原则的使用
  • 接口隔离原则_动力节点Java学院整理
  • PHP面向对象五大原则之开放-封闭原则(OCP)详解
  • PHP面向对象五大原则之接口隔离原则(ISP)详解
(0)

相关推荐

  • 接口隔离原则_动力节点Java学院整理

    定义:客户端不应该依赖它不需要的接口:一个类对另一个类的依赖应该建立在最小的接口上. 问题由来:类A通过接口I依赖类B,类C通过接口I依赖类D,如果接口I对于类A和类B来说不是最小接口,则类B和类D必须去实现他们不需要的方法. 解决方案:将臃肿的接口I拆分为独立的几个接口,类A和类C分别与他们需要的接口建立依赖关系.也就是采用接口隔离原则. 举例来说明接口隔离原则: (图1  未遵循接口隔离原则的设计) 这个图的意思是:类A依赖接口I中的方法1.方法2.方法3,类B是对类A依赖的实现.类C依赖接

  • 简单理解遵循接口隔离原则的Java设计模式编程

    定义:客户端不应该依赖它不需要的接口:一个类对另一个类的依赖应该建立在最小的接口上. 问题由来:类A通过接口I依赖类B,类C通过接口I依赖类D,如果接口I对于类A和类B来说不是最小接口,则类B和类D必须去实现他们不需要的方法. 解决方案:将臃肿的接口I拆分为独立的几个接口,类A和类C分别与他们需要的接口建立依赖关系.也就是采用接口隔离原则. 举例来说明接口隔离原则: 这个图的意思是:类A依赖接口I中的方法1.方法2.方法3,类B是对类A依赖的实现.类C依赖接口I中的方法1.方法4.方法5,类D是

  • 举例说明Java设计模式编程中ISP接口隔离原则的使用

    Interface Segregation Principle,ISP接口隔离原则主张使用多个专门的接口比使用单一的总接口要好. 一个类对另外一个类的依赖性应当是建立在最小的接口上的. 一个接口代表一个角色,不应当将不同的角色都交给一个接口.没有关系的接口合并在一起,形成一个臃肿的大接口,这是对角色和接口的污染. "不应该强迫客户依赖于它们不用的方法.接口属于客户,不属于它所在的类层次结构."这个说得很明白了,再通俗点说,不要强迫客户使用它们不用的方法,如果强迫用户使用它们不使用的方法

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

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

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

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

  • 深入理解JavaScript系列(21):S.O.L.I.D五大原则之接口隔离原则ISP详解

    前言 本章我们要讲解的是S.O.L.I.D五大原则JavaScript语言实现的第4篇,接口隔离原则ISP(The Interface Segregation Principle). 英文原文:http://freshbrewedcode.com/derekgreer/2012/01/08/solid-javascript-the-interface-segregation-principle/ 注:这篇文章作者写得比较绕口,所以大叔理解得也比较郁闷,凑合着看吧,别深陷进去了 接口隔离原则的描述

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

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

  • C#实现六大设计原则之单一职责原则

    单一职责(SRP)定义: 不要存在多于一个导致类变更的原因,通俗的说,即一个类只负责一项职责. 问题由来: 类T负责两个不同的职责:职责P1,职责P2.当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常的职责P2功能发生故障. 解决方案: 遵循单一职责原则.分别建立两个类T1.T2,使T1完成职责P1功能,T2完成职责P2功能.这样,当修改类T1时,不会使职责P2发生故障风险:同理,当修改T2时,也不会使职责P1发生故障风险. ps: 说到单一职责原则,很多人都会不屑一顾.因为

  • Java设计模式七大原则之单一职责原则详解

    目录 定义 案例 需求 方案一 方案二 对比分析 总结 如何遵守单一职责原则 定义 单一职责原则(Single Responsibility Principle, SRP),有且仅有一个原因引起类的变更.简单来说,就是针对一个java类,它应该只负责一项职责.例如一个Test.java类,它有两个职责:职责1,职责2.当职责1进行修改时,有可能影响到职责2,所以需要将Test.java类拆分成Test1.java和Test2.java两个单一职责的类. 案例 需求 有一个交通工具类,里面定义一个

  • C#面向对象设计原则之单一职责原则

    单一职责原则(SRP) 定义:系统中的每一个类都应该只有一个职责. 好处:高内聚.低耦合. 解释说明: 单一职责也就是说我们应该让一个类或一个对象只做一件事情,每个类所要关注的就是自己要完成的职责是什么,能够引起这个类变化的原因也应该只有一个,这也是后面提到的所有的设计模式都会遵守的一个原则. 高内聚:先按照面向对象的封装特性来理解,封装也就是我们说的,应该把一个类或对象它所有相关的属性.方法.行为放到一起,放到一个类中,这样就实现了一个封装的特性.那么内聚,就是一个类里面应该包含它所有的属性和

  • python面向对象编程设计原则之单一职责原则详解

    目录 一,封装 (一)什么是封装 (二)封装与访问 (三)私有化与访问控制 1,属性与方法的私有化 2,变量名压缩 3,方法重载 (四)属性引用:getter.setter与property 二,单一职责原则 (一)一个不满足单一职责原则的例子 (二)单一职责原则 三,封装与单一职责原则 总结 一,封装 封装是面向对象编程思想的重要特征之一. (一)什么是封装 封装是一个抽象对象的过程,它容纳了对象的属性和行为实现细节,并以此对外提供公共访问. 这样做有几个好处: 分离使用与实现.可直接使用公共

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

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

  • 单一职责原则_动力节点Java学院整理

    定义:不要存在多于一个导致类变更的原因.通俗的说,即一个类只负责一项职责. 问题由来:类T负责两个不同的职责:职责P1,职责P2.当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常的职责P2功能发生故障. 解决方案:遵循单一职责原则.分别建立两个类T1.T2,使T1完成职责P1功能,T2完成职责P2功能.这样,当修改类T1时,不会使职责P2发生故障风险:同理,当修改T2时,也不会使职责P1发生故障风险. 说到单一职责原则,很多人都会不屑一顾.因为它太简单了.稍有经验的程序员即使

  • C# 实例解释面向对象编程中的单一功能原则(示例代码)

    在面向对象编程领域中,单一功能原则(Single responsibility principle)规定每个类都应该有且仅有一个单一的功能,并且该功能应该由这个类完全封装起来. 在面向对象编程中,SOLID 是五个设计原则的首字母缩写,旨在使软件设计更易于理解.灵活和可维护.这些原则是由美国软件工程师和讲师罗伯特·C·马丁(Robert Cecil Martin)提出的许多原则的子集,在他2000年的论文<设计原则与设计模式>中首次提出. SOLID 原则包含: S:单一功能原则(single

  • 简单讲解Java设计模式编程中的单一职责原则

    单一职责原则:一个类,只有一个引起它变化的原因. 为什么需要单一职责原则? 如果一个类有多个原因要去修改它,那么修改一个功能时,可能会让其他功能产生Bug,所以一个类最好只有一个职责.但实际应用中还是比较难实现的,我们只能是尽量符合这个原则. 有时候,开发人员设计接口的时候会有些问题,比如用户的属性和用户的行为被放在一个接口中声明.这就造成了业务对象和业务逻辑被放在了一起,这样就造成了这个接口有两种职责,接口职责不明确,按照SRP的定义就违背了接口的单一职责原则了. 下面是个例子: packag

  • Java设计模式之单一职责原则精解

    1.什么是单一职责原则? 首先我们可以对某个类来说,即一个类应该只负责一项职责.如类A负责两个不同职责: 职责1,职责2.当职责1需求变更而改变A时,可能造成职责2执行错误,所以需要将类A的粒度分解为A1,A2. 我们来看下面这段代码: package com.szh.principle.singleresponsibility; /** * 交通工具类 * 方式1 * 1. 在方式1的run方法中,违反了单一职责原则 * 2. 解决的方案非常的简单,根据交通工具运行方法不同,分解成不同类即可

随机推荐