Analyse de cas d'utilisation du principe d'isolation d'interface PHP (ISP)

Cette fois, je vais vous apporter une analyse des cas d'utilisation du principe d'isolation d'interface PHP (ISP). Quelles sont les précautions d'utilisation du principe d'isolation d'interface PHP (ISP) ? Ce qui suit est un cas pratique, prenons un exemple. regarder.

Lors de la conception d'une application, si un module contient plusieurs sous-modules, nous devons alors faire attention à l'abstraction du module. En supposant que le module est implémenté par une classe, nous pouvons abstraire le système dans une interface. Mais lors de l'ajout d'un nouveau programme d'extension de module, si le module à ajouter ne contient que quelques sous-modules dans le système d'origine, alors le système nous obligera à implémenter toutes les méthodes dans l'interface, et nous devrons écrire des méthodes stupides. De telles interfaces sont appelées interfaces lourdes ou interfaces polluées. L'utilisation de telles interfaces introduira des comportements inappropriés dans le système. Ces comportements inappropriés peuvent conduire à des résultats incorrects et également à un gaspillage de ressources.

1. Ségrégation des interfaces

Le principe de ségrégation des interfaces (ISP) stipule que les clients ne devraient pas être obligés de mettre en œuvre quelque chose qu'ils ne savent pas comment à faire L'interface utilisée doit regrouper les méthodes dans la grosse interface, puis la remplacer par plusieurs interfaces, chaque interface servant un sous-module. En termes simples, il est bien préférable d’utiliser plusieurs interfaces spécialisées plutôt qu’une seule.

Les principaux points d'ISP sont les suivants :

1) La dépendance d'une classe par rapport à une autre classe doit être basée sur la plus petite interface.

Le FAI peut atteindre l'objectif de ne pas forcer les clients (méthodes d'utilisation de l'interface) à s'appuyer sur des méthodes qu'ils n'utilisent pas. La classe d'implémentation de l'interface ne doit présenter qu'un rôle à responsabilité unique (suivant le SRP). principe)

Le FAI peut également réduire l'interaction entre les clients --- lorsqu'un client exige de nouvelles responsabilités (nécessite des changements) et force l'interface à changer, la possibilité d'affecter d'autres programmes clients est minime.

2) Le programme client ne doit pas s'appuyer sur des méthodes d'interface (fonctions) dont il n'a pas besoin.

Le programme client doit dépendre de méthodes d'interface (fonctions) dont il n'a pas besoin. Cela dépend de l'interface requise. Fournissez l’interface dont le client a besoin et éliminez les interfaces inutiles. Cela nécessite d’affiner l’interface pour garantir sa pureté.

Par exemple, lors de l'héritage, la sous-classe héritera de toutes les méthodes disponibles dans la classe parent ; et certaines méthodes de la classe parent peuvent ne pas être nécessaires dans la sous-classe. Par exemple, les employés ordinaires et les managers héritent tous deux de l'interface employé. Les employés doivent rédiger des journaux de travail chaque jour, mais pas les managers. Par conséquent, les journaux de travail ne peuvent pas être utilisés pour bloquer les gestionnaires, c'est-à-dire que les gestionnaires ne doivent pas se fier à la méthode de soumission des journaux de travail.

On peut voir que les concepts des FAI et SRP se chevauchent dans une certaine mesure. En fait, de nombreux modèles de conception se chevauchent conceptuellement, et il est même difficile de dire à quel modèle de conception appartient un morceau de code.

ISP souligne que l'interface promet le moins possible au client, et qu'elle doit être précise. Lorsque les exigences d'un certain programme client changent, obligeant l'interface à changer, la possibilité d'affecter d'autres programmes clients est faible. Il s’agit en réalité d’un problème de pollution d’interface.

2. Pollution de l'interface

Une conception d'interface trop gonflée est une pollution de l'interface. La soi-disant pollution de l'interface consiste à ajouter des responsabilités inutiles à l'interface. Si le développeur ajoute une nouvelle fonction à l'interface simplement pour réduire le nombre de classes d'implémentation de l'interface, cette conception entraînera une « pollution » et une « graisse » continue de l'interface. " .

« L'isolation de l'interface » est en fait le principe de la conception de services personnalisés. Utilisez l'héritage multiple d'interfaces pour combiner différentes interfaces afin de fournir des fonctions de combinaison externes --- pour obtenir des « services à la demande ».

L'interface doit être démontée, mais elle ne peut pas être démontée trop finement. Il doit y avoir un standard, qui soit à haute cohésion. L'interface doit avoir quelques fonctions de base et peut accomplir de manière unique une tâche de base.

Dans les applications pratiques, vous rencontrerez les problèmes suivants : Par exemple, si j'ai besoin d'une implémentation DAO qui peut s'adapter à plusieurs types de bases de données, alors je dois d'abord implémenter une interface opération de base de données, qui stipule certaines bases de données Méthodes de fonctionnement de base, telles que connexion à la base de données, ajout, suppression, modification et vérification, fermeture de la base de données, etc. Il s'agit d'une interface peu fonctionnelle. Pour certaines méthodes uniques à MySQL mais n'existant pas dans d'autres bases de données ou de nature différente, comme la méthode MySQL pconnect qui peut être utilisée en PHP, le même concept que cette méthode n'existe pas dans d'autres bases de données, donc cette méthode n'existe pas. Il devrait apparaître dans cette interface de base, alors quelles méthodes de base cette interface de base devrait-elle avoir ? PDO vous l'a dit.

PDO est une couche d'interface de base de données abstraite, qui nous indique quelles méthodes de base une interface d'opération de base de données doit implémenter. L'interface est une abstraction de haut niveau, les méthodes de l'interface doivent donc être universelles, basiques et difficiles à modifier.

Il y a une autre question : comment ces méthodes uniques devraient-elles être mises en œuvre ? Selon le principe du FAI, ces méthodes peuvent exister dans une autre interface, permettant à cette « hétérogène » d'implémenter les deux interfaces en même temps.

Pour la pollution des interfaces, vous pouvez envisager ces deux méthodes de traitement :

Utiliser la délégation pour séparer les interfaces.

Utilisez l'héritage multiple pour séparer les interfaces.

En mode délégation, deux objets participent au traitement de la même requête. L'objet acceptant la requête délègue la requête à un autre objet pour traitement, comme le mode stratégie, le mode proxy. , etc. La notion de délégation est appliquée dans les deux cas.

Jetons un coup d'oeil aux exemples

Avez-vous déjà rencontré une interface très "grosse" ?

Par exemple : il y a une interface liée aux animaux, le code est le suivant :

<?php
interface Animal{
  public function walk();
  public function speak();
}

Dog est une implémentation spécifique de cette interface :

<?php
require_once "animal.php";
class Dog implements Animal{
  public function walk(){
    echo "dogs can walk";
  }
  public function speak(){
    echo "dogs can speak";
  }
}

ok, maintenant nous voulons créer un poisson qui sait nager, que devons-nous faire ? Nous devons modifier l'interface, ce qui affectera également l'implémentation de la classe dog, et fish doit également implémenter les méthodes walk et talk, comme indiqué dans le code suivant :

Classe d'interface Animal :

<?php
interface Animal{
  public function walk();
  public function speak();
  public function swim();
}

Classe chien :

<?php
require_once "animal.php";
class Dog implements Animal{
  public function walk(){
    echo "dogs can walk";
  }
  public function speak(){
    echo "dogs can speak";
  }
  public function swim(){
  }
}

Classe poisson :

<?php
require_once "animal.php";
class Fish implements Animal{
  public function walk(){
  }
  public function speak(){
  }
  public function swim(){
    echo "fish can swim";
  }
}

À l'heure actuelle, la classe d'interface Animal montre les caractéristiques d'une interface "grosse". La soi-disant interface grasse signifie en fait que l'interface définit des méthodes qui ne sont pas requises par toutes les classes d'implémentation. Tout comme la classe d'interface Animal, certains animaux ne peuvent pas nager, certains animaux ne peuvent pas marcher et certains animaux ne peuvent pas voler. Si ces méthodes sont écrites dans une classe d’interface Animal, alors l’expansion et la maintenance ultérieures seront un désastre.

Alors, comment résoudre les problèmes ci-dessus ?

C'est très simple, il suffit d'affiner l'interface et de diviser la classe d'interface Animal en trois classes d'interface :

Classe d'interface animalCanWalk :

<?php
interface animalCanSpeak{
  public function speak();
}

Classe d'interface AnimalCanSwim :

<?php
interface AnimalCanSwim{
  public function swim();
}

Classe d'interface animalCanSpeak :

<?php
interface animalCanSpeak{
  public function speak();
}

Après avoir défini ces classes d'interface, l'implémentation de dog et fish sera beaucoup plus facile,

<?php
require_once "animalCanSpeak.php";
require_once "animalCanWalk.php";
class Dog implements animalCanSpeak,animalCanWalk{
  public function walk(){
    echo "dogs can walk";
  }
  public function speak(){
    echo "dogs can speak";
  }
}

<?php
require_once "animalCanSwim.php";
class Fish implements AnimalCanSwim{
  public function swim(){
    echo "fish can swim";
  }
}

Pour résumer :

Le concept du principe de ségrégation des interfaces (ISP) : Utiliser plusieurs interfaces spécialisées au lieu d'une seule interface globale, c'est-à-dire que le client ne doit pas s'appuyer sur sur les interfaces, il n'est pas nécessaire.

Lors de l'utilisation du principe d'isolation d'interface, nous devons faire attention au contrôle de la granularité de l'interface. Si elle est trop petite, cela entraînera une prolifération d'interfaces. dans le système, ce qui n'est pas propice à la maintenance ; l'interface ne doit pas être trop grande, ni trop petite. Une grande interface violera le principe d'isolation de l'interface, aura une faible flexibilité et sera très peu pratique à utiliser. D'une manière générale, l'interface doit uniquement contenir des méthodes personnalisées pour un certain type d'utilisateur, et les clients ne doivent pas être obligés de s'appuyer sur des méthodes qu'ils n'utilisent pas.

Je pense que vous maîtrisez la méthode après avoir lu le cas dans cet article. Pour des informations plus intéressantes, veuillez prêter attention aux autres articles connexes sur le site Web chinois de php !

Lecture recommandée :

Explication détaillée du cas d'inversion de dépendance PHP

Explication détaillée des étapes pour créer un package Composer en 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!