• 6 heures
  • Moyenne

Ce cours est visible gratuitement en ligne.

course.header.alt.is_video

course.header.alt.is_certifying

J'ai tout compris !

Mis à jour le 16/02/2024

I comme Interface Segregation Principle

Découvrez le principe de ségrégation d’interface

Le quatrième principe SOLID commence donc par la lettre I pour "Interface Segregation Principle".

Nous pourrions le traduire de cette façon : "Vous ne devriez pas avoir à implémenter des méthodes dont vous n’avez pas besoin." L’idée ici est d’éviter d’avoir des interfaces aux multiples responsabilités et de les redécouper en multiples interfaces qui ont, elles, une seule responsabilité.

Finalement, ce principe revisite le premier principe (Single Responsibility Principle), en l’appliquant cette fois à nos interfaces.

Mettez en application le principe de ségrégation d'interface

Nous allons changer d’exemple (le calcul de prix de livraison ne doit plus être un sujet qui vous amuse, de toute façon :D). Profitons-en pour utiliser à nouveau un exemple adapté d’un projet open source connu, car même du code éprouvé par de nombreux développeurs et développeuses peut toujours être amélioré. Voici l’interface en question :

<?php

interface UrlFileCheckerInterface
{
    /**
     * Check if .htaccess file for Front Office is writable.
     *
     * @return bool
     */
    public function isHtaccessFileWritable() : bool;

    /**
     * Check if robots.txt file for Front Office is writable.
     *
     * @return bool
     */
    public function isRobotsFileWritable() : bool;
}

Cette interface a l’air propre : que peut-on lui reprocher ? :-°

Dans les deux cas, nous vérifions qu’un fichier soit accessible en écriture. Mais en quoi vérifier que le fichier .htaccess  est accessible en écriture a un rapport avec les accès du fichier robots.txt ? Et admettons que sur un projet, je veuille réutiliser cette interface, mais que je n’aie pas de fichier .htaccess, car le projet utilise le logiciel serveur Nginx plutôt que le logiciel Apache.

Je vais alors devoir implémenter une fonction qui sera inutile au projet.

Voilà comment nous pourrions améliorer cela :

<?php

interface IsHtaccessFileWritableInterface
{
    /**
     * Check if .htaccess file for Front Office is writable.
     *
     * @return bool
     */
    public function isWritable();
}

interface IsRobotsFileWritableInterface
{
    /**
     * Check if robots.txt file for Front Office is writable.
     *
     * @return bool
     */
    public function isWritable();
}

Mais, quand on y réfléchit... avons-nous réellement besoin d’une interface par fichier ? Améliorons encore cela.

<?php

interface FileWritableInterface
{
    /**
     * Check if a file is writable.
     *
     * @return bool
     */
    public function isWritable();
}

class IsHtaccessFileWritable implements FileWritableInterface
{
    /**
     * {@inheritdoc}
     */
    public function isWritable()
    {
        /*...*/
    }
}

class IsRobotsFileWritable implements FileWritableInterface
{
    /**
     * {@inheritdoc}
     */
    public function isWritable()
    {
        /*...*/
    }
}

Je viens de réappliquer un des principes SOLID précédemment expliqués : saurez-vous deviner lequel ?  ;)

Il s'agit des deux derniers principes que nous avons vus ensemble : Open/Closed Principle et Liskov Substitution Principle !

Exercez-vous !

Cette fois un exercice rapide, téléchargez cette archive qui ne contient qu'une seule interface et deux implémentations.

À l'aide des commentaires de l'interface et du code des deux classes, proposez deux interfaces, de sorte que les classes n'aient plus à implémenter de code inutile !

Vous en profiterez pour créer ces deux interfaces, et adapter le code des classes pour qu'elles utilisent vos nouvelles interfaces, au besoin. 

En résumé

  • Nous réappliquons tous les principes vus jusque-là pour améliorer nos "interfaces".

  • Dans un monde parfait, idéal... chaque interface n'aurait qu'une seule fonction à implémenter, qu'un seul "contrat" !

  • Dans la pratique, ce n'est pas si idéal que ça ("Implémenter 15 interfaces, mais ça va pas la tête ?! :colere:"), on regroupe donc les fonctions qui sont nécessaires pour une fonctionnalité importante.

  • Refactorisez et découpez vos interfaces quand vous avez besoin d'en utiliser une, mais que vous savez que vous n'avez pas l'utilité de toutes les contraintes qu'elle impose à votre implémentation :magicien:.

Nous attaquerons le dernier principe SOLID dans le prochain chapitre, mais vous êtes déjà de bien meilleurs développeurs et développeuses maintenant. :soleil: 

Exemple de certificat de réussite
Exemple de certificat de réussite