Compréhension approfondie de la série JavaScript (21) : Explication détaillée du principe d'isolation d'interface FAI des cinq principes de S.O.L.I.D_Basic knowledge

Avant-propos

Ce que nous allons expliquer dans ce chapitre est le quatrième des cinq principes d'implémentation du langage JavaScript S.O.L.I.D, le principe de ségrégation d'interface ISP (principe de ségrégation d'interface).

Texte original en anglais :http://freshbrewedcode.com/derekgreer/2012/01/08/solid-javascript-the-interface-segregation-principle/
Remarque : L'auteur de cet article est assez alambiqué, donc l'oncle est assez déprimé quand il le comprend. Il suffit de le lire et de ne pas trop s'y plonger
. La description du principe d'isolation de l'interface est la suivante :

Copier le code Le code est le suivant :

Les clients ne devraient pas être obligés de dépendre de méthodes qu’ils n’utilisent pas.

Les clients ne devraient pas être obligés de s'appuyer sur des méthodes qu'ils n'utilisent pas.

Lorsqu'un utilisateur s'appuie sur une méthode d'interface qui n'est utilisée que par d'autres utilisateurs mais pas par lui-même, il doit implémenter ces interfaces. En d'autres termes, un utilisateur s'appuie sur une interface qui n'est pas utilisée mais est utilisée par d'autres utilisateurs. . Lorsque d'autres utilisateurs Lorsque cette interface est modifiée, tous les utilisateurs qui en dépendent seront affectés. Cela viole évidemment le principe ouvert-fermé et n’est pas ce à quoi nous nous attendons.

Le principe d'isolation d'interface ISP est quelque peu similaire à la responsabilité unique. Ils sont tous deux utilisés pour regrouper les responsabilités fonctionnelles. En fait, ISP peut être compris comme la conversion d'un programme avec une seule responsabilité en un objet avec une interface publique.

Interface JavaScript

Comment respecter ce principe sous JavaScript ? Après tout, JavaScript n'a pas les caractéristiques d'une interface. Si l'interface est ce que nous voulons établir un contrat et découpler via un type abstrait fourni par un certain langage, alors on peut dire que tout va bien, mais JavaScript a une autre forme. d'interface. Dans le livre Design Patterns – Elements of Realistic Object-Oriented Software on retrouve la définition de l’interface :
http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612

Toute opération déclarée par un objet contient un nom d'opération, un objet paramètre et la valeur de retour de l'opération. Nous appelons cela la signature de l'opérateur.
Toutes les opérations déclarées dans un objet sont appelées l'interface de l'objet. L'interface d'un objet décrit toutes les informations de requête qui se produisent sur cet objet.
Qu'un langage fournisse ou non une construction distincte pour représenter une interface, tous les objets ont une interface implicite composée de toutes les propriétés et méthodes de l'objet. Référez-vous au code suivant :

Copier le code Le code est le suivant :

var exempleBinder = {};
exempleBinder.modelObserver = (function() {
/* Variables privées */
Retour {
         observer : fonction(modèle) {
                                                  /* Code */
               return newModel ;
},
onChange : fonction (rappel) {
                                                  /* Code */
>
>
})();

exempleBinder.viewAdaptor = (function() {
/* Variables privées */
Retour {
           bind : fonction (modèle) {
                                                  /* Code */
>
>
})();

exempleBinder.bind = fonction (modèle) {
/* Variables privées */
ExempleBinder.modelObserver.onChange(/* rappel */);
var om = exampleBinder.modelObserver.observe(model);
ExempleBinder.viewAdaptor.bind(om);
Retour om;
};

La fonction implémentée par la bibliothèque de classes exampleBinder ci-dessus est une liaison bidirectionnelle. L'interface publique exposée par cette bibliothèque de classes est la méthode bind. Les fonctions de notification de modification et d'interaction de vue utilisées dans bind sont respectivement implémentées par des objets distincts modelObserver et viewAdaptor. Dans un sens, ces objets sont l'interface publique bind. la méthode.

Bien que JavaScript ne fournisse pas de type d'interface pour prendre en charge le contrat d'un objet, l'interface implicite de l'objet peut toujours être fournie aux utilisateurs du programme sous forme de contrat.

FAI et JavaScript

Certaines des sections dont nous discutons ci-dessous portent sur l'impact de la violation du principe d'isolation de l'interface en JavaScript. Comme vu ci-dessus, il est dommage d'implémenter le principe d'isolation d'interface dans les programmes JavaScript, mais il n'est pas aussi puissant qu'un langage typé statiquement. Les caractéristiques du langage JavaScript rendent parfois ce qu'on appelle l'interface un peu non collante.

Réalisation de la Chute

Dans les langages typés statiquement, l'une des raisons pour lesquelles le principe du FAI est violé est une implémentation défectueuse. Toutes les méthodes définies dans les interfaces en Java et C# doivent être implémentées. Si vous n'en avez besoin que de quelques-unes, les autres méthodes doivent également être implémentées (soit par une implémentation vide, soit en lançant une exception). En JavaScript, si vous n'avez besoin que de certaines interfaces dans un objet, cela ne peut pas résoudre le problème d'implémentation corrompue, bien qu'il ne soit pas nécessaire d'imposer l'implémentation des interfaces ci-dessus. Mais cette implémentation viole toujours le principe de substitution de Liskov.

Copier le code Le code est le suivant :

var rectangle = {
Zone : fonction() {
          /* Code */
},
Dessiner : fonction() {
          /* Code */
>
};

var géométrieApplication = {
GetLargestRectangle : fonction (rectangles) {
          /* Code */
>
};

var dessinApplication = {
drawRectangles : fonction (rectangles) {
         /* Code */
>
};

Lorsqu'un substitut de rectangle satisfait le getLargestRectangle du nouvel objet GeometryApplication, il n'a besoin que de la méthode Area() du rectangle, mais il viole LSP (car il n'utilise pas du tout la méthode draw qui peut être utilisée par la méthode drawRectangles .

Couplage statique

Une autre raison des violations des FAI dans les langages typés statiquement est le couplage statique. Dans les langages typés statiquement, les interfaces jouent un rôle important dans un programme de conception faiblement couplé. Que ce soit dans un langage dynamique ou un langage statique, un objet peut parfois avoir besoin de communiquer entre plusieurs utilisateurs clients (comme dans le cas d'un état partagé). Pour les langages typés statiquement, la meilleure solution consiste à utiliser des interfaces de rôle, qui permettent aux utilisateurs et à l'objet d'interagir ( et l'objet peut devoir jouer plusieurs rôles), car sa mise en œuvre dissocie l'utilisateur des actions non liées. Ce problème n’existe pas en JavaScript, car les objets sont découplés grâce aux avantages uniques des langages dynamiques.

Couplage sémantique

Une raison courante qui conduit à des violations du FAI, à la fois dans les langages dynamiques et dans les langages typés statiquement, est le couplage sémantique. Ce qu'on appelle le couplage sémantique est une dépendance mutuelle, c'est-à-dire que le comportement d'un objet dépend d'un autre objet. , ce qui signifie que si un utilisateur modifie l'un des comportements, cela affectera probablement un autre utilisateur. Cela viole également le principe de responsabilité unique. Ce problème peut être résolu par l'héritage et la substitution d'objets.

Évolutivité

Une autre raison du problème est l'évolutivité. De nombreuses personnes donneront des exemples de rappel pour démontrer l'évolutivité (comme les paramètres de rappel après un succès en ajax). Si une telle interface nécessite une implémentation et qu'il existe de nombreuses familiarités ou méthodes dans l'objet implémenté, ISP deviendra très important, c'est-à-dire que lorsqu'une interface devient une interface qui doit implémenter de nombreuses méthodes, sa mise en œuvre deviendra extrêmement complexe. , et peut amener ces interfaces à assumer une responsabilité non collante. C'est ce que nous appelons souvent de grosses interfaces.

Résumé

Les fonctionnalités dynamiques du langage JavaScript rendent notre implémentation d'interfaces non collantes moins influente que les langages typés statiquement, mais le principe d'isolation des interfaces a toujours sa place dans le modèle de programmation JavaScript.