Explication détaillée des cinq principes orientés objet de PHP et du principe d'isolation de l'interface

Les exemples de cet article décrivent le principe d'isolation d'interface (ISP) des cinq principes orientés objet de PHP. Partagez-le avec tout le monde pour votre référence, comme suit : <br>

Lors de la conception d'une application, si un module contient plusieurs sous-modules, nous devons alors veiller à faire 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) indique que les clients ne doivent pas être obligés d'implémenter des interfaces qu'ils n'utilisent pas et doivent regrouper les méthodes dans de grosses interfaces, puis les remplacer par plusieurs interfaces, chacune desservant 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 principe SRP) <.>

FAI également Il peut réduire l'influence mutuelle 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) Les programmes clients ne doivent pas s'appuyer sur des méthodes d'interface (fonctions) dont ils n'ont 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 capable de s'adapter à plusieurs types de bases de données, je dois d'abord implémenter une interface d'opération de base de données, qui stipule certaines méthodes de base d'opérations de base de données. , tels que Se connecter à la base de données, ajouter, supprimer, modifier et interroger, fermer 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. La notion de délégation s'applique en mode stratégie, mode proxy, etc.

Regardons les 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 :

<br>

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

Le chien appartient à cette interface A implémentation spécifique :

<br>

1. <?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 :

<br>

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

catégorie chien :

<br>

1. <?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(){
     }
   }

catégorie poisson :

<br>

1. <?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 fat 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 :

animalCanWalk接口类：

<br>

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

AnimalCanSwim接口类：

<br>

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

animalCanSpeak接口类：

<br>

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

定义好这几个接口类之后，dog和fish的实现就容易多了，

<br>

1. <?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";
     }
   }

<br>

接口隔离原则(Interface Segregation Principle, ISP)的概念：使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。

在使用接口隔离原则时，我们需要注意控制接口的粒度，接口不能太小，如果太小会导致系统中接口泛滥，不利于维护；接口也不能太大，太大的接口将违背接口隔离原则，灵活性较差，使用起来很不方便。一般而言，接口中仅包含为某一类用户定制的方法即可，不应该强迫客户依赖于那些它们不用的方法。

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!