Si vous vous sentez à l’aise avec le principe de responsabilité unique, le principe de ségrégation des interfaces vous semblera parfaitement logique. Il s’agit du même principe, mais appliqué aux interfaces :
Une interface (représentée par une classe abstraite ne définissant que certains attributs – vides – en Python) doit décrire un ensemble de comportements.
Vous pouvez rencontrer les mêmes problèmes avec les interfaces qu’avec les classes. Il vous faut ajouter une nouvelle capacité à une interface existante, plutôt que d’en créer une nouvelle. Maintenant, toutes les classes chargées d’implémenter doivent prendre en compte un élément supplémentaire. 😐
En vous assurant que vos interfaces restent petites et pertinentes, vous diminuez le couplage. Le couplage désigne à quel point deux éléments de logiciel sont liés. Plus une interface définit d’éléments, plus une classe qui implémente doit en faire à son tour. Cette situation rend cette classe moins réutilisable.
En raison de la célèbre fonctionnalité de duck typing (littéralement, typage de canard) de Python, les interfaces ne sont pas utilisées aussi largement que dans d’autres langages de programmation. Si un objet marche comme un canard et nage comme un canard, alors Python est satisfait de le traiter comme un canard, même s’il s’agit en réalité d’un cygne ! 🦢
Malgré tout, vous vous retrouverez fréquemment dans une situation où vous voudrez que deux classes (ou plus) agissent comme alternative l’une à l’autre, même si elles n’implémentent aucune interface explicite. Dans ce cas, le principe de ségrégation des interfaces s’applique toujours ! Il vous dit de ne pas exposer de méthodes inutiles dans ces classes. En effet, si vous le faites, vous devrez ajouter une méthode équivalente à toutes ses alternatives.
Comment appliquer le principe de ségrégation des interfaces à notre code ?
À la demande générale, des spectateurs du monde entier veulent regarder notre passionnante partie de cartes à la télévision et en streaming sur Internet. Faisons de ce rêve une réalité ! 🎥 📺
Nous aurons besoin de trois sortes de vue différentes :
PlayerView(VuePourJoueur) : les joueurs interagissent avec celle-ci (renommée depuis View) ;BroadcastView(VuePourDiffusion) ;InternetStreamingView(VuePourStreamingInternet).
Est-ce que nous utilisons toujours le design pattern MVC ? Ou est-ce que c’est plutôt un pattern du type MVVVC à cause des vues supplémentaires ?
Il s’agit toujours de MVC ! Notre vue contient simplement plusieurs composantes, tout comme notre modèle contient les composantes Card , Deck et Player .
Suivez avec votre propre copie du code pendant que nous effectuons cette tâche ensemble !
Voici le lien vers le code.
Notre solution fonctionne, mais certaines parties du codage semblent… plutôt inutiles. Certaines des méthodes – comme BroadcastView.prompt_for_flip_cards – ont dû être implémentées avec attention, juste pour qu’elles n’aient jamais aucun effet sur le jeu.
Ces méthodes ne doivent clairement jamais être appelées, et ne devraient pas avoir besoin d’être implémentées. C’est un signe clair que nous enfreignons le principe de ségrégation des interfaces !
Que pouvons-nous faire différemment ?
Rappelons-nous notre objectif : nous voulons que BroadcastView et InternetStreamingView ne contiennent que les méthodes suivantes :
show_player_and_hand;show_winner.
Nous devons donc réécrire notre code pour que nos vues n’aient besoin que de ces deux méthodes par défaut, sauf s’il s’agit de PlayerView .
Essayez par vous-même – en annulant vos modifications de la vidéo précédente si nécessaire – puis regardez une solution possible dans la vidéo ci-dessous :
Voici le lien vers le code.
Nous avons réussi à écrire une série d’objets de la vue alternatifs, qui ne sont pas encombrés par des méthodes inutiles, malgré la fonctionnalité supplémentaire qui a besoin d’être conservée dans PlayerView .
En résumé
La ségrégation des interfaces correspond au principe de responsabilité unique pour les interfaces.
Ce principe est facile à enfreindre. Il peut être tentant d’ajouter une nouvelle méthode à une interface existante, vu qu’elle fait déjà quelque chose.
En cas de doute, il vaut mieux avoir deux interfaces avec peu de méthodes à implémenter, qu’une seule interface qui ait trop de responsabilités.
Au chapitre suivant, nous verrons comment garantir que nos implémentations de bas niveau ne dirigent pas les implémentations des classes de niveau plus élevé !
