PHP 단일 책임 원칙(SRP) 사용 사례 분석

이번에는 PHP 단일 책임 원칙(SRP) 사용 사례에 대한 분석을 가져오겠습니다. PHP 단일 책임 원칙(SRP) 사용 시 주의 사항은 무엇인가요? 다음은 실제 사례입니다.

단일 책임 원칙(SRP)

단일 책임에는 두 가지 의미가 있습니다. 하나는 동일한 책임을 다른 클래스로 분산시키지 않는 것이고, 다른 하나는 한 클래스가 너무 많은 책임을 맡는 것을 방지하는 것입니다

우리가 준수해야 하는 이유 SRP를 사용하면

(1) 클래스 간 결합을 줄일 수 있습니다

클래스 간 결합을 줄이면 요구 사항이 변경될 때 하나의 클래스만 수정되므로 클래스가 여러 개 있는 경우 변경 사항이 격리됩니다. 한 가지 책임이 변경되면 다른 책임에 영향을 미칠 수 있습니다.

(2) 클래스 재사용성 향상

컴퓨터를 개조하는 것이 TV를 수리하는 것보다 훨씬 쉽습니다. 주된 이유는 TV의 다양한 구성 요소 간의 결합도가 너무 높기 때문입니다. 그러나 컴퓨터의 메모리, 하드 디스크, 사운드 카드, 네트워크 카드, 키보드 조명 및 기타 구성 요소는 쉽게 분해 및 조립할 수 있습니다. 갈라져. 부품이 파손된 경우 새 부품으로 교체하면 됩니다. 위의 예는 단일 책임의 장점을 보여줍니다. 단일 책임을 사용하기 때문에 '구성 요소'를 쉽게 '분해'하고 '조립'할 수 있습니다.

SRP를 준수하지 않으면 클래스 재사용성에 영향을 미칩니다. 클래스의 특정 책임만 사용해야 하는 경우 다른 책임과 결합되어 분리가 어렵습니다.

SRP를 준수하는 것이 실제 코드 개발에 적용되나요? 일부. 데이터 지속성 계층을 예로 들면 소위 데이터 지속성 계층은 주로 데이터베이스 작업과 캐시 관리 등을 의미합니다. 이때 데이터 지속성 계층은 여러 데이터베이스를 지원해야 합니다. 무엇을 해야 합니까? 여러 데이터베이스 작업 클래스를 정의하시겠습니까? 아이디어는 이미 매우 유사하며 다음 단계는 팩토리 패턴을 사용하는 것입니다.

Factory 패턴(Faction)을 사용하면 코드가 실행될 때 개체를 인스턴스화할 수 있습니다. '객체 생성'을 담당한다고 해서 팩토리 패턴(Factory Pattern)이라고 합니다. 데이터베이스를 예로 들면, 팩토리에 필요한 것은 다양한 매개변수를 기반으로 다양한 인스턴스화된 객체를 생성하는 것입니다. 가장 간단한 팩토리는 전달된 유형 이름을 기반으로 객체를 인스턴스화하는 것입니다. 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;
    }
  }
}

이제 if 필요한 데이터베이스 작업 방법은 무엇입니까? 팩토리 클래스를 정의하고 다양한 입력에 따라 필요한 클래스를 생성하기만 하면 됩니다. 호출 시에는 다음과 같이 작성하면 됩니다.

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');
  }
}

데이터베이스를 생성합니다

이 프로그램을 별도로 연결합니다. 프로그램의 CURD는 데이터베이스에 대해 걱정할 필요가 없으며 사양에 따라 해당 방법을 사용하면 됩니다.

Factory 메소드는 구체적인 객체가 더 이상 구체적인 클래스가 아닌 추상화에 의존하도록 해제합니다.

디자인 패턴의 명령 패턴도 SRP의 구현입니다. 명령 패턴은 "

명령 요청자

"와 "

명령 구현자"의 책임을 분리합니다. 이해하기 쉬운 예를 들자면, 식사를 주문하기 위해 레스토랑에 가면 레스토랑에는 고객, 웨이터, 셰프라는 세 가지 역할이 있습니다. 고객은 메뉴 목록을 작성하고 웨이터에게 전달해야 하며, 웨이터는 셰프에게 이를 실행하도록 지시합니다. 웨이터로서 식사 준비 방법만 부르면 됩니다(셰프에게 "볶을 시간이에요"라고 부르세요). 셰프가 볶으라는 요청을 들으면 바로 요리를 해준다. 여기서 명령의 요청과 구현은 완전히 분리됩니다. 이 과정을 시뮬레이션하려면 먼저 요리사의 역할을 정의하면 요리사가 실제로 요리하고 수프를 만드는 작업을 수행하게 됩니다.

다음은 예시입니다

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

웨이터의 차례입니다. 보통 식당에 가면 웨이터에게 직접 전화할 수 없습니다. “웨이터, 튀긴 토마토 한 접시 주세요.” 따라서 웨이터는 고객과 요리사 사이에서 주문을 전달하는 역할을 합니다.

/**
 * 厨师类，命令接受者与执行者
 * 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 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里氏替换案例详解

Bootstrap+PHP实现多图上传步骤详解

위 내용은 PHP 단일 책임 원칙(SRP) 사용 사례 분석의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!