Analyse de cas d'utilisation du principe de responsabilité unique (SRP) PHP

Cette fois, je vais vous présenter une analyse de cas du principe de responsabilité unique PHP (SRP). Quelles sont les précautions à prendre pour utiliser le principe de responsabilité unique PHP (SRP) ? Ce qui suit est un cas pratique, jetons un coup d'oeil.

Principe de responsabilité unique (PRS)

La responsabilité unique a deux significations : L'une est d'éviter de répartir les mêmes responsabilités entre les différentes classes, l'autre est d'éviter qu'une classe prenne trop de responsabilités

Pourquoi devrions-nous nous conformer au SRP ?

(1) Cela peut réduire le couplage entre les classes

Si vous réduisez le couplage entre les classes, lorsque les exigences changent, une seule classe est modifiée, isolant ainsi le changement ; si une classe a plusieurs responsabilités différentes, elles sont couplées entre elles, et lorsqu'une responsabilité change, peut interférer avec les autres. responsabilités.

(2) Améliorer la réutilisabilité des cours

Modifier un ordinateur est bien plus simple que réparer un téléviseur. La raison principale est que le couplage entre les différents composants du téléviseur est trop élevé, mais il est différent de celui de l'ordinateur : la mémoire, le disque dur, la carte son, la carte réseau, l'éclairage du clavier et d'autres composants peuvent être facilement démontés et assemblés. séparément. Si une pièce est cassée, remplacez-la simplement par une neuve. L’exemple ci-dessus démontre les avantages d’une responsabilité unique. Grâce à l'utilisation d'une responsabilité unique, les « composants » peuvent être facilement « démontés » et « assemblés ».

Le non-respect du SRP affectera la réutilisabilité des cours. Lorsqu’il suffit d’utiliser une certaine responsabilité de la classe, il est difficile de la dissocier car elle est couplée à d’autres responsabilités.

Le respect du SRP a-t-il une application dans le développement réel du code ? quelques. En prenant la couche de persistance des données comme exemple, la couche dite de persistance des données fait principalement référence aux opérations de base de données, et bien sûr, à la gestion du cache, etc. À l’heure actuelle, la couche de persistance des données doit prendre en charge plusieurs bases de données. Que faut-il faire ? Définir plusieurs classes d'opérations de base de données ? L’idée est déjà très proche. La prochaine étape consiste à utiliser le modèle d’usine.

Factory pattern (Faction) permet d'instancier des objets lorsque le code est exécuté. On l’appelle Factory Pattern car il est responsable de la « production d’objets ». En prenant la base de données comme exemple, l'usine a besoin de générer différents objets instanciés en fonction de différents paramètres. L'usine la plus simple consiste à instancier un objet en fonction du nom de type transmis. S'il est transmis à MySQL, il appelle la classe MySQL et l'instancie. S'il s'agit de SQLite, il appelle la classe SQLite et l'instancie. gérer la base de données de classe TXT, Execl, etc.

La classe usine est une telle classe. Elle est uniquement responsable de la production des objets, mais pas du contenu spécifique des objets.

Ce qui suit est un exemple

Définir une interface d'adaptateur

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

Définir une opération de base de données MySQL qui implémente l'interface DB_AdpaterClass

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

Définissez une classe d'opération de base de données SQLite qui implémente l'interface DB_Adpater

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

Maintenant, si vous avez besoin d'une méthode d'opération de base de données, il vous suffit de définir une classe d'usine, selon Il suffit de passer les différentes classes nécessaires à la génération

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

Lors de l'appel, vous pouvez écrire comme ceci

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

On sépare le créer une base de donnéesprogramme de connexion Retirez-le, et le CURD du programme n'a besoin de se soucier d'aucune base de données, utilisez simplement la méthode correspondante selon les spécifications.

Les méthodes d'usine libèrent les objets concrets pour qu'ils ne dépendent plus de classes concrètes, mais de l'abstraction. Le modèle de commande dans le modèle de conception

est également l'incarnation de SRP. Le modèle de commande sépare les responsabilités du "demandeur de commande " et du "implémenteur de commande ". Pour donner un exemple bien compris, si vous allez au restaurant pour commander un repas, le restaurant a trois rôles : client, serveur et chef. En tant que client, vous devez lister le menu et le transmettre au serveur, qui demande ensuite au chef de le mettre en œuvre. En tant que serveur, il vous suffit d'appeler la méthode de préparation des repas (appeler le chef « C'est l'heure de faire sauter ») Lorsque le chef entend la demande de faire sauter, il cuisinera immédiatement. Ici, la demande et la mise en œuvre de la commande sont complètement découplées.

Pour simuler ce processus, définissez d'abord le rôle du chef, et le chef fera réellement le travail de cuisine et de préparation de la soupe.

Ce qui suit est un exemple

/**
 * 厨师类，命令接受者与执行者
 * 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();
}

C'est le tour du serveur. Le serveur est le transmetteur des commandes. Habituellement, lorsque vous allez manger au restaurant, vous appelez le serveur. Je n'appelle pas directement le chef. Vous appelez généralement le serveur. "Serveur, apporte-moi une assiette de tomates frites." Le serveur est donc le communicateur des commandes entre le client et le chef.

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

Les clients peuvent désormais appeler le serveur selon le menu

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实现多图上传步骤详解

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!