TP3 – Qualité du code - Les principes SOLID SOLID, Qualité, Interface, Abstraction, Héritage, Composition, Injection de dépendances, Design Patterns

Attention, si vous aviez déjà commencé ce TP lors de votre dernière séance, il faut mettre à jour votre dépôt local avec les dernières modifications du dépôt d’origine ! :

# Depuis le dossier de votre dépôt, en local.
git remote add upstream git@gitlabinfo.iutmontp.univ-montp2.fr:qualite-de-developpement-semestre-3/tp3.git
git fetch upstream
git merge upstream/master master

Dans la première partie de cette ressource, nous avons parlé de conception logicielle et notamment comment modéliser cela à l’aide de diagrammes de classes de conception et de diagrammes de séquences des interactions.

Cependant, savoir modéliser la conception ne garantit en rien la qualité de celle-ci. Un plan de construction d’un bâtiment peut être tout à fait valide d’un point de vue technique, mais donnera potentiellement une bâtisse qui s’écroulera dans quelques années si elle a été mal pensée.

On a la même logique au niveau du développement logiciel. Un logiciel mal conçu peut répondre à un besoin et satisfaire le client et ses utilisateurs dans l’immédiat, mais il sera alors très difficile de le faire évoluer sur la durée.

De manière générale, les principes liés à la qualité du développement s’assurent que le logiciel que vous allez construire pourra évoluer facilement tout en satisfaisant les besoins actuels.

Tout cela est difficile à mettre en place au premier abord, car il peut parfois être bien plus rapide et facile de développer une solution peu qualitative, mais qui fonctionne. Néanmoins, le code produit ne tiendra pas au fur et à mesure que l’application va grossir ce qui conduira finalement à la réécriture d’une partie voir de la totalité du code ou pire, l’abandon du projet.

C’est un phénomène qui touche beaucoup d’entreprises du monde du développement. Face au besoin de délivrer une solution rapidement, l’aspect qualité est parfois négligé. Au bout de plusieurs années, il est très compliqué d’ajouter de nouvelles fonctionnalités et d’éviter les bugs. Une nouvelle personne rentrant dans le projet ne comprend rien au code. Le client n’est plus satisfait, car les nouvelles fonctionnalités sont délivrées moins fréquemment et de plus en plus de bugs apparaissent. C’est une barque qui prend l’eau sur laquelle on place du sparadrap pour boucher les trous. Mais à chaque fois qu’un trou est bouché, deux nouveaux apparaissent. Le client transfère le projet à une autre entreprise, qui ne comprend rien à ce qu’elle récupère… Plus formellement, on dit que la dette technique s’accumule.

Tout cela est aussi dur pour le développeur. Travailler dans un tel environnement est très désagréable et peut même dégoûter du développement. Jusqu’ici, vous avez travaillé sur des projets relativement petits (même pour vos SAEs) mais vous devriez être plus conscients de cette problématique après votre période de stage ou d’alternance.

L’ingénieur doit avoir une vision à long terme et prendre en compte les évolutions possibles de son programme. Pour l’aider dans cette tâche, il dispose de différents outils : les principes liés à la qualité du code, comme les principes SOLID et aussi les design patterns. La maîtrise de ces outils différencie un codeur (une IA ?) d’un ingénieur. Le codeur sait produire du code, l’ingénieur sait produire des logiciels durables.

Les frameworks sont des outils qui englobent différents design patterns et “forcent” le développeur (de par leur structure) à respecter un certain niveau de qualité dans la conception (parfois, sans qu’il s’en rende compte). Nous allons étudier plusieurs frameworks l’année prochaine.

Bref, dans ce cours, nous allons commencer par nous intéresser aux principes SOLID qui constituent la porte d’entrée vers un programme bien conçu. Nous allons également commencer à parler de design patterns (nous allons en introduire 2) mais nous les étudierons plus en détail dans les prochains TP.

Les principes SOLID

Les principes SOLID représentent un acronyme lié aux 5 principes clés pour obtenir un logiciel qualitatif :

• Le principe de responsabiltié unique (Single responsability)

• Le principe ouvert/fermé (Open/Close)

• Le principe de substitution de Liskov (Liskov substitution)

• Le principe de ségrégation des interfaces (Interface segregation)

• Le principe d’inversion des dépendances (Dependency inversion)

Le respect de ces principes permet d’améliorer le principe de faible couplage et de forte cohésion des classes (que nous avons abordé précédemment), l’évolutivité du logiciel, la réduction du risque de bugs liés à l’architecture…

Les design patterns sont des solutions à des problèmes bien définis qui fournissent des modèles réutilisables et adaptables sur n’importe quel projet. Ces patterns permettent notamment de respecter les principes SOLID.

Dans un logiciel développé d’une telle manière, généralement, l’ajout d’une nouvelle fonctionnalité se résume à l’ajout de nouvelles classes ou de méthodes sans avoir besoin de modifier ou de récrire les classes existantes. Le programme est ouvert à l’extension, mais fermé aux modifications (qui pourraient entraîner elles-mêmes d’autres modifications…).

Dans ce TP, nous allons étudier chaque principe et nous allons vous fournir du code qui est (la plupart du temps) fonctionnel, mais développé sans respecter SOLID. Vous allez alors constater que :

• Il est difficile d’ajouter de nouvelles choses.
• L’ajout de fonctionnalités ou d’éléments entraîne la modification de multiples classes.
• Des bugs parfois assez inattendus peuvent survenir.
• Les tests unitaires sont difficiles à gérer.

Ensuite, nous allons voir comme un des principes SOLID permet de régler cela, et vous allez donc devoir refactorer les différentes applications. Refactorer du code (ou réusiner du code en français) signifie retravailler le code source du programme sans pour autant ajouter de nouvelles fonctionnalités à l’application. Il s’agit d’améliorer la qualité du code.

Ce projet contient divers paquetages contenant le code de base pour chaque exercice que nous allons traiter.

Principe de responsabilité unique (Single Responsability)

Pour mener à bien le déroulement d’une fonctionnalité, le programme va faire appel à diverses classes qui vont interagir entre elles (comme nous l’avons vu avec le DSI). Ces classes vont traiter la demande. Chaque classe possède la responsabilité d’effecteur une partie de ce traitement.

Le principe de responsabilité unique indique qu’une classe ne doit pas posséder plus d’une responsabilité. Une responsabilité concerne des opérations (traitement, méthodes) de même nature. Nous avions déjà abordé cela plus tôt dans le cours sur les diagrammes de séquences en parlant d’architecture centralisée et distribuée. Nous avions vu qu’une distribution du traitement (et donc des responsabilités) était plus conseillée. C’est un peu le même principe ici.

Robert C. Martin dit : “Si une classe a plus d’une responsabilité, alors ces responsabilités deviennent couplées. Des modifications apportées à l’une des responsabilités peuvent porter atteinte ou inhiber la capacité de la classe de remplir les autres. Ce genre de couplage amène à des architectures fragiles qui dysfonctionnent de façon inattendue lorsqu’elles sont modifiées.”

En bref, une classe ne doit changer que pour une seule raison. Si diverses raisons liées à des responsabilités différentes impliquent de modifier la classe, le principe de responsabilité unique n’est donc pas respecté.

Par exemple, considérons le code suivant :

class Email {

   private String sujet;

   private String[] destinataires;

   private String contenu;

   public Email(String sujet, String[] destinataires, String contenu) {
      this.sujet = sujet;
      this.destinataires = destinataires;
      this.contenu = contenu;
   }

   public String getSujet() {
      return sujet;
   }

   public String[] getDestinataires() {
      return destinataires;
   }

   public void envoyer() {
      //Code complexe pour envoyer un mail...
   }

}

class Main {

   public static void main(String[]args) {
      Email m = new Email("Hello", new String[]{"test@example.com"}, "Hello world!");
      m.envoyer();
   }

}

Ici, la classe Email a deux responsabilités clairement identifiables : stocker les informations d’un mail et l’envoyer. Le principe de responsabilité unique n’est donc pas respecté. Pour régler cela, il faudrait donc mettre en place une nouvelle classe qui se charge de l’envoi d’un mail :

class Email {

   private String sujet;

   private String[] destinataires;

   private String contenu;

   public Email(String sujet, String[]destinataires, String contenu) {
      this.sujet = sujet;
      this.destinataires = destinataires;
      this.contenu = contenu;
   }

   public String getSujet() {return sujet;}

   public String[] getDestinataires() {return destinataires;}

}

class ServeurMail {

  public void envoyerMail(Email mail) {
      //Code complexe pour envoyer un mail...
  }

}

class Main {

   public static void main(String[]args) {
      Email e = new Email("Hello", new String[]{"test@example.com"}, "Hello world!");
      ServeurMail serveur = new ServeurMail();
      serveur.envoyerMail(e);
   }

}

Ici, chaque classe à une responsabilité unique : si la logique pour envoyer un mail change, la classe Email n’est pas impactée.

Le principe de responsabilité unique s’applique également aux paquetages : chaque paquetage est lié à une responsabilité du programme. Par exemple, sur le TP JDBC que vous faites en bases de données, chaque paquetage à un rôle (et donc une responsabilité) précis : IHM, controllers, services, stockage… (et on pourrait (même devrait) aller plus en détail).

Ce principe semble assez facile à mettre en place, mais dans la réalité, on retrouve malheureusement des classes (et des paquetages) “fourre-tout” qui deviennent illisibles au fur et à mesure de l’évolution du programme. Si votre classe a trop de méthode, c’est peut-être qu’elle possède plus d’une responsabilité et que celles-ci pourraient être mieux réparties.

Bien sûr, ce premier exercice est très simpliste, mais il faut vous imaginer que les différentes responsabilités sont généralement des traitements plus longs et/ou plus complexes !

Voyons maintenant un autre exemple.

Principe Ouvert/Fermé (Open/Close)

Après cette mise en bouche, il est temps d’attaquer de sérieux problèmes de conception en développant le principe ouvert/fermé. Ce principe est défini comme suit :

“Les entités d’un logiciel (classes, modules, fonctions) doivent être ouverts aux extensions, mais fermés aux modifications.” (Bertand Meyer).

En d’autres termes, il doit être possible d’étendre les fonctionnalités/le comportement d’une entité comme une classe sans pour autant avoir besoin de modifier son code source.

Ce principe est un pilier fondamental de qualité de code. Avec ce principe, même une classe ou une librairie compilée (non modifiable) autorise le développeur à étendre les fonctionnalités proposées.

Malheureusement, dans de nombreux projets, on rencontre fréquemment des classes violant ce principe, car mal conçues. Les symptômes sont généralement :

• l’utilisation d’un énorme bloc if/else if/else ou d’un switch case qui grossit au fur et à mesure qu’on ajoute de nouvelles choses. Avec l’utilisation de classes et de l’héritage, on va en plus certainement se retrouver à utiliser des instructions instanceof (pour vérifier le type de l’objet) et de cast pour pouvoir utiliser des méthodes précises.
• nécessité de dupliquer du code pour ajouter une nouvelle fonctionnalité (non-respect du principe DRY).

Pour vous mettre dans le bain et vous montrer la problématique derrière tout cela, vous allez ajouter de nouvelles fonctionnalités à des projets existants qui ne respectent pas le principe ouvert/fermé.

Votre programme fonctionne ? C’est super ! Mais votre code serait-il encore lisible s’il y avait une centaine d’animaux ?

Continuons maintenant avec de petits monstres bien populaires : les pokémons.

Le programme sur lequel nous allons travailler fait combattre des pokémons dans un simulateur. Il y a différents types de pokémons (feu, eau, plante…) et chaque type de pokémon possède une attaque (le type feu attaque toujours avec lance-flamme). Bien sûr, cette analyse est un peu bizarre et ne correspond pas à la réalité du jeu (où chaque pokémon possède plusieurs attaques, et pas une attaque précise selon le type) mais nous allons l’utiliser ainsi pour ne pas plus compliquer l’exercice.

En plus de l’attaque, le type de pokémon est aussi lié à un nombre de dégâts. Par exemple, le type feu fait toujours 60 dégâts et le type plante entre 40 et 80 dégâts.

Pour modéliser tout cela, le développeur a choisi de mettre en place un héritage pour gérer les différents types. Pour savoir quelle attaque annoncer dans le simulateur et quels dégâts infliger, il a besoin de vérifier quel est le pokémon qui attaque.

De même, dans la classe Pokemon, pour que le pokémon puisse se présenter avec son type (dans la méthode toString), la classe vérifie son type concret.

Si ce n’était peut-être pas encore assez évident avec les animaux, à ce stade, vous devez vous rendre compte qu’ajouter un nouveau type de pokémon est fastidieux :

• Créez une classe du type correspondant.

• Implémenter une méthode donnant les dégâts de ce type.

• Modifier la classe SimulateurCombat en ajoutant un nouveau else if pour prendre en charge le nouveau type, faire un cast pour récupérer ses dégâts…

• Modifier la classe Pokemon pour adapter le toString en ajoutant un nouveau else if pour prendre en charge le nouveau type.

De plus, ici, seules deux fonctions ont vraiment besoin de connaître les détails des pokémons. Mais que se passerait-il s’il y avait beaucoup plus de méthodes et de classes qui en dépendent ? À chaque ajout d’un nouveau type, il faudrait modifier l’ensemble de ces classes et de ces méthodes ! Dans un gros projet, cela deviendrait vite un calvaire. De plus, il est facile d’oublier de mettre à jour une classe, ce qui ne provoque pas d’erreur de compilation, mais un bug lors de l’exécution (comme avec les animaux inconnus). Donc, la dette technique va croître beaucoup trop vite.

Le respect du principe ouvert/fermé va permettre de se limiter aux deux premières étapes : création d’une classe et implémentation des méthodes nécessaires dans cette même classe.

Considérons l’exemple suivant, similaire à ce que vous venez de faire :

class FigureGeometrique {

   private String typeFigure;

   public FigureGeometrique(String typeFigure) {
      this.typeFigure = typeFigure;
   }

   public void dessiner() {
      if(typeFigure == "rectangle") {
         dessinerRectangle();
      }
      else if(typeFigure == "triangle") {
         dessinerTriangle();
      }
   }

   private void dessinerRectangle() {
      //Code pour dessiner un rectangle...
   }

   private void dessinerTriangle() {
      //Code pour dessiner un triangle...
   }

}

L’ajout d’une nouvelle figure géométrique (par exemple, un carré) nécessite la modification de la classe FigureGeometrique et de la méthode dessiner. Le principe ouvert/fermé n’est pas respecté. De plus, un bug (à l’exécution) se produira si on essaie de traiter une figure géométrique qui n’existe pas !

Pour régler ce problème, l’idée est de se reposer sur un système d’héritage et d’abstraction :

• FigureGeometrique est une classe abstraite, qui permet d’imposer un comportement uniforme aux figures (méthode abstraite dessiner)
• Chaque type de figure géométrique donnera donc lieu à une classe spécialisée et l’attribut type de FigureGeometrique perd son utilité :

abstract class FigureGeometrique {

  public abstract void dessiner();

}

class Rectangle extends FigureGeometrique {

  public void dessiner() {
    //Code pour dessiner un rectangle...
  }
}

class Triangle extends FigureGeometrique {

  public void dessiner() {
    //Code pour dessiner un triangle...
  }
}

L’ajout d’une nouvelle figure nécessite donc simplement l’ajout d’une nouvelle classe correspondant à la figure et l’implémentation des méthodes requises (ici, dessiner la figure). Aucune autre classe n’est modifiée. L’extension est possible (ajout de nouvelles figures) sans modification du code source déjà présent. Par ailleurs, il est maintenant impossible de créer des figures géométriques qui n’existent pas au préalable dans notre programme (c’est une bonne chose !).

Comme FigureGeometrique ne contient aucun attribut (qui pourraient être communs à toutes les figures) et définit simplement des méthodes abstraites, il serait plus judicieux d’utiliser une interface ! Par contre, si la classe abstraite possède des attributs et/ou définit un bout de comportement commun à toutes les sous-classes, on utilisera bien une classe abstraite.

Ceci devrait vous permettre de refactorer le code du paquetage ocp1 (animaux). Pour ocp2 (pokémons) cela peut sembler un peu plus dur (car il y a déjà un système d’héritage), mais cela ne devrait pas être trop dur à adapter.

En comparant vos deux diagrammes de classes, on peut facilement voir ce qui différencie la “mauvaise” conception de la “bonne” : dans votre premier diagramme, les classes SimulateurCombat et Pokemon ont autant de dépendances qu’il y a de sous-classes de type de pokémon. S’il y a 30 types de pokémons, SimulateurCombat et Pokemon auront chacune 30 dépendances. Après refactoring, ces dépendances disparaissent. SimulateurCombat est seulement dépendant de Pokemon.

Dans un code de qualité les abstractions ne dépendent pas des implémentations. En d’autres termes, une superclasse ne devrait pas dépendre de ses sous-classes. Seules les sous-classes peuvent dépendre de leurs parents (et on verra que parfois, là aussi, il faut faire attention lorsqu’on utilise l’héritage.). Sur votre premier diagramme, il est clair que ce principe n’est pas respecté, car Pokemon dépendait de ses différentes sous-classes, ce qui n’est plus les cas sur le deuxième diagramme.

Nous allons mettre à l’épreuve votre compréhension des deux principes (S et O) avec un nouvel exercice un peu différent de ce que vous venez de voir, dans sa forme.

Comme vous l’avez sans doute déduit, dans un premier temps, le principe ouvert/fermé n’est pas respecté : ajouter un nouveau tri demande de modifier le code source de la classe Paquet et notamment la méthode trier.

Dans un second temps, on remarque aussi que la classe Paquet a peut-être un peu trop de responsabilités : cela ne devrait pas être à elle de trier les cartes ! On pourrait aussi dire la même chose pour le mélange, et peut-être même pour l’affichage ! La vérification peut se faire facilement :

• Si la méthode de tri change, la classe Paquet doit être modifiée.

• Si la méthode de mélange change, la classe Paquet doit être modifiée.

• Si le format d’affichage du paquet change, la classe Paquet doit être modifiée.

Le principe de responsabilités unique n’est pas respecté. Pour le toString, cela peut encore se discuter, mais cela est clair pour le tri et le mélange.

Les principes SOLID se combinent naturellement entre eux. D’ailleurs, si vous avez refactoré proprement le dernier exercice, vous avez même déjà utilisé le principe d’inversion des dépendances dont nous parlerons plus tard !

Encore mieux, vous venez d’utiliser votre premier design pattern au niveau des tris : Stratégie. Ce pattern permet d’injecter un comportement spécifique dans une classe sans en modifier le code source (et éventuellement, le modifier plus tard). Ce pattern s’appuie sur ouvert/fermé, l’inversion des dépendances et aide à renforcer responsabilité unique. C’est exactement ce que vous venez de faire : la méthode de tri du paquet est modulable et on peut même en ajouter des nouvelles dans le futur ! Et tout cela, sans modifier Paquet.

À partir du diagramme de classes de conception que vous venez de réaliser, vous devriez être en mesure de généraliser le pattern stratégie à tout type de problème.

Héritage, composition et principe ouvert-fermé

Certains développeurs abusent de l’héritage par facilité au lieu d’utiliser d’autres solutions comme la composition d’objets. Un “mauvais” héritage est un héritage où il n’existe pas vraiment de relation de spécialisation entre la superclasse et la sous-classe. La sous-classe ne représente alors pas le même concept que sa classe mère, ce n’est pas vraiment une spécialisation.

Tout cela occasionne des bugs parfois inattendus.

Nous venons de voir que l’héritage impose une vigilance accrue lors du refactoring.

Maintenant, voyons une nouvelle situation, où les choses risquent d’être plus compliquées notamment vis-à-vis du respect du principe ouvert/fermé !

Si vous vous êtes contenté uniquement de faire hériter ProduitAvecDatePeremptionProche de Produit, vous remarquerez qu’il est impossible d’avoir un même produit possédant ces deux fonctionnalités à la fois. Avec un héritage multiple, il y aurait pu y avoir une solution (moche), mais nous avons vu qu’il est déconseillé de faire cela et de toute façon, dans beaucoup de langages (dont Java), ce n’est pas possible.

Tout en respectant le principe ouvert/fermé, il existe une méthode pour construire un Produit possédant autant de comportements mixtes que nous souhaitons. On peut le régler en favorisant la composition au lieu d’un héritage. L’idée est que la classe “fille” n’hérite pas de la classe mère en redéfinissant simplement les fonctions, mais possède à la place un attribut stockant une instance de cette classe et l’utilise. Si en plus, on a besoin que les deux classes soient du même type, alors on utilise une interface.

Illustrons le problème et sa solution :

class Salarie {

   private double salaire;

   public Salarie(double salaire) {
      this.salaire = salaire;
   }

   public double getSalaire() {
      return salaire;
   }

}

class ChefProjet extends Salarie {

   private int nombreProjetsGeres;

   public ChefProjet(double salaire, int nombreProjetsGeres) {
      super(salaire);
      this.nombreProjetsGeres = nombreProjetsGeres;
   }

   @Override
   public double getSalaire() {
      return super.getSalaire() + 100 * (nombreProjetsGeres);
   }

}

class ResponsableDeStagiaires extends Salarie {

   private int nombreStagiairesGeres;

   public ResponsableDeStagiaires(double salaire, int nombreStagiairesGeres) {
      super(salaire);
      this.nombreStagiairesGeres = nombreStagiairesGeres;
   }

   @Override
   public double getSalaire() {
      return super.getSalaire() + 50 * nombreStagiairesGeres;
   }
}

Ici, même problème que pour les produits, si je veux un salarié qui est à la fois chef de projet et responsable de stagiaire, cela est impossible !

Comme souvent, l’héritage est le problème ici. Au lieu de faire un simple héritage entre les classes, nous pourrions plutôt utiliser des compositions sur les sous-types et créer ainsi des salariés incluant des salariés, incluant des salariés… ce qui permet de combiner la logique de chaque type !

interface I_Salarie {
  double getSalaire();
}


class Salarie implements I_Salarie {

  private double salaire;

  public Salarie(double salaire) {
    this.salaire = salaire;
  }

  public double getSalaire() {
    return salaire;
  }

}

class ChefProjet implements I_Salarie {

  private I_Salarie salarie;

  private int nombreProjetsGeres;

  public ChefProjet(I_Salarie salarie, int nombreProjetsGeres) {
    this.salarie = salarie;
    this.nombreProjetsGeres = nombreProjetsGeres;
  }

  @Override
  public double getSalaire() {
    return salarie.getSalaire() + 100 * (nombreProjetsGeres);
  }

}

class ResponsableDeStagiaires implements I_Salarie {

  private I_Salarie salarie;

  private int nombreStagiairesGeres;

  public ResponsableDeStagiaires(I_Salarie salarie, int nombreStagiairesGeres) {
    this.salarie = salarie;
    this.nombreStagiairesGeres = nombreStagiairesGeres;
  }

  @Override
  public double getSalaire() {
    return salarie.getSalaire() + 50 * nombreStagiairesGeres;
  }
}

Avec cette nouvelle architecture, nous pouvons créer des salariés qui sont chefs de projet et responsables de stagiaires :

//Salarié qui est chef de projet gérant 3 projets et aussi responsable de stagiaires gérant 5 stagiaires
I_Salarie salarie = new ResponsableStagiaires(new ChefProjet(new Salarie(2000), 3), 5);
salarie.getSalaire(); //Renvoie 2550

Il est important de noter que la classe composée est I_Salarie et non pas Salarie! Sinon, on ne pourrait pas combiner ChefProjet avec ResponsableStagiaires.

Aussi, le salarie n’est pas instancié dans la classe, il est injecté (autrement, cela ne fonctionnerait pas), comme ce que vous avez fait, par exemple, avec l’exercice sur le paquet de carte et les différentes méthodes de tri. Sur un diagramme de classes de conception, cela pourrait être représenté par une agrégation blanche.

Attention, même si nous pouvons maintenant rajouter un nouveau type de produit et le combiner aux autres pour calculer le prix adéquat, quand on instancie l’objet, il faut faire attention à l’ordre de combinaison des objets.

Bon, tout fonctionne bien, mais le code est encore un peu redondant : A priori, tous nos produits “dérivés” vont posséder un objet I_Produit. Il est alors possible de factoriser cela avec une classe abstraite dont vont hériter tous les sous-produits.

Par exemple, pour l’exemple des salariés :

//Nous reviendrons sur le nom "decorator" plus tard.
abstract class SalarieDecorator implements I_Salarie {
   protected I_Salarie salarie;

   public SalarieDecorator(I_Salarie salarie) {
      this.salarie = salarie;
   }

   public double getSalaire() {
      return salarie.getSalaire();
   }
}

class ResponsableDeStagiaires extends SalarieDecorator {

  private int nombreStagiairesGeres;

  public ResponsableDeStagiaires(I_Salarie salarie, int nombreStagiairesGeres) {
    super(salarie);
    this.nombreStagiairesGeres = nombreStagiairesGeres;
  }

  @Override
  public double getSalaire() {
    return super.getSalaire() + 50 * nombreStagiairesGeres;
  }

}

Dans le futur, si nous ajoutons un nouveau type de produit, il suffira alors de rajouter une nouvelle classe et lui faire étendre votre classe abstraite. Avec une telle architecture, le principe ouvert/fermé est respecté et nous avons tiré profit de manière avantageuse du mécanisme de composition au lieu de se reposer sur l’héritage qui ne nous permettait pas d’arriver à nos fins.

En fait, ce modèle est réutilisable et adaptable à d’autres situations (nous l’avons vu avec les salariés). C’est en fait un autre design pattern nommé décorateur d’où le nom de la classe abstraite dans l’exemple.

À partir du diagramme de classes que vous avez réalisé, vous devriez être capable de produire un modèle général fonctionnant pour vous.

Principe de substitution de Liskov (Liskov substitution)

Le principe de substitution de Liskov a été introduit par Barbara Liskov et énonce qu’un objet d’une superclasse donnée doit pouvoir être remplacée par une de ses sous-classes sans casser le fonctionnement du programme. Une méthode provenant à l’origine d’une superclasse et appelée sur la sous-classe devrait produire le même résultat que si elle avait été appelée sur la superclasse.

L’utilisation inappropriée de l’héritage peut amener au non-respect de ce principe. Voici un scénario illustrant le problème de non-respect du principe de substitution de Liskov : on possède une classe Rectangle et on souhaite modéliser une classe Carre. D’ailleurs, en géométrie, un carré est une sorte de rectangle…

Avec cette modification, le principe de substitution de Liskov n’est toujours pas respecté ! En effet, si on utilise Carre comme un Rectangle, des bugs étranges surviennent quand on utilise une méthode prévue pour un Rectangle (ici, la méthode agrandirRectangle). On ne peut pas substituer le rectangle par un carré sans produire de bugs logiques.

Un autre “patch” possible serait d’ajouter une fonction setTailleCote dans Carre et redéfinition des fonctions setHauteur et setLargeur dans Rectangle de façon à ce qu’elles ne fassent rien :

class Carre extends Rectangle {

  public Carre(int tailleCote) {
    super(tailleCote, tailleCote);
  }

  public void setTailleCote(int tailleCote) {
    this.hauteur = tailleCote;
    this.largeur = tailleCote;
  }

  @Override
  public void setHauteur(int hauteur) {}

  @Override
  public void setLargeur(int largeur) {}
  
}

Mais dans ce cas, on ne peut plus utiliser Carre comme un Rectangle et en plus :

• on crée des méthodes qui ne font rien et qui polluent le code
• on duplique le code de setHauteur et setLargeur dans Carre dans setTailleCote !

Bref, cet héritage est une très mauvaise idée ! En fait, conceptuellement, en programmation, un carré n’est pas un rectangle spécialisé, car les règles pour la hauteur et la largeur sont différentes…cela peut être un peu dur à accepter.

Si on souhaite quand même utiliser un rectangle dans un carré (pour ne pas dupliquer le calcul de l’aire ou des autres méthodes, par exemple) on peut éventuellement utiliser une composition comme nous l’avons vu dans l’exercice sur les comptes bancaires, en interdisant à un Carre de redéfinir sa hauteur et sa largeur.

Après refactoring, le diagramme de classes de votre application devrait donner quelque-chose comme ça :

La composition forte entre Carre et Rectangle (initialisé dans Carre et n’en sort pas) est en opposition avec la composition faible, qui indique aussi une composition, mais dans laquelle la dépendance est injectée (comme avec les décorateurs dans l’exercice des produits).

Bien sûr, nous aurions pu quand même conserver la logique d’agrandissement d’une FigureRectangulaire. À ce moment-là, il faudrait rajouter une méthode agrandir(int facteur) dans l’interface FigureRectangulaire et implémenter les méthodes dans Rectangle et Carre.

Mettons vos nouvelles connaissances en pratique avec un autre exercice.

Le dernier test n’est pas mal rédigé, car, selon le contrat de Pile, seules les opérations estVide, empiler, depiler et sommetPile doivent produire un effet. Or, comme Pile hérite de Vector, on a accès à toutes les opérations réalisables sur une liste classique… Donc, dans la logique, même s’il est possible d’appeler remove sur notre Pile, cela ne doit produire aucun effet ! Or, ce n’est pas le cas ici.

On pourrait redéfinir la méthode remove (et toutes les méthodes de Vector !) pour qu’elles ne fassent rien, mais le principe de substitution de Liskov ne serait alors plus respecté ! On ne pourrait pas substituer un Vector par une Pile.

Bref, conceptuellement, une Pile n’est pas un Vector spécial, mais bien une structure indépendante… Néanmoins, il est possible d’utiliser une composition pour utiliser un Vector comme attribut, dans notre classe Pile.

Eh oui, même les concepteurs de Java ont fait quelques bêtises lors du développement du langage. Et il n’est plus possible de supprimer cette classe après coup pour ne pas causer de problèmes de compatibilité. La seule chose à faire est de déprécier cette classe et de conseiller une nouvelle solution mieux conçue. D’où l’importance de bien penser sa conception !

Principe de ségrégation des interfaces (Interface segregation)

Le quatrième principe SOLID est le principe de ségrégation des interfaces.

Un objet ne doit pas être forcé de dépendre de méthodes qu’il n’utilise pas. Globalement, il ne faut pas qu’une interface définisse dans son contrat des méthodes qui ne seront voir ne pourront pas être implémentées par la classe implémentant l’interface.

Nous en avons déjà parlé, mais une interface est un contrat. Une classe qui implémente une interface est forcé d’implémenter toutes les méthodes de l’interface. Mais une classe ne devrait pas être forcée à implémenter un bout de contrat qu’elle ne peut pas remplir.

Voyons comment ne pas respecter ce principe peut devenir très fastidieux au fur et à mesure que le projet grossit.

C’était pénible, n’est-ce pas ? C’est normal, cette solution est très mauvaise et fastidieuse. À chaque nouvel ajout de type de monture avec ses spécificités, on doit modifier tous les autres types et les forcer à implémenter des méthodes qui ne les concernent pas… Le fait de lever tant d’erreurs indique une très mauvaise conception.

Si le développeur avait bien raison de vouloir faire une interface lors de la création de la première monture, il a voulu regrouper trop de chose dans une seule et même interface : les méthodes communes à toutes les montures (nom, vitesse) et la méthode concernant l’endurance, spécifique aux montures terrestres. Par la suite, on a continué dans cette mauvaise logique. Il aurait dû dès le départ diviser cela en deux interfaces et on aurait dû créer plus d’interfaces à chaque nouveau type de monture ayant ses spécificités.

On rappelle qu’une interface peut hériter d’une autre interface ! Et qu’une classe peut implémenter autant d’interfaces qu’elle le désire.

Imaginons l’exemple suivant :

interface I_Exemple {
  void operationGlobale();
  void operationA();
  void operationB();
  void operationC();
}

class A implements I_Exemple {
  public void operationGlobale() {
    //Code...
  }

  public void operationA() {
    //Code...
  }

  public void operationB() {
    throw new Error("Impossible d'implémenter cette méthode.");
  }

  public void operationC() {
    throw new Error("Impossible d'implémenter cette méthode.");
  }
}

class B implements I_Exemple {
  public void operationGlobale() {
    //Code...
  }

  public void operationA() {
    throw new Error("Impossible d'implémenter cette méthode.");
  }

  public void operationB() {
    //Code
  }

  public void operationC() {
    throw new Error("Impossible d'implémenter cette méthode.");
  }
}

class C implements I_Exemple {
  public void operationGlobale() {
    //Code...
  }

  public void operationA() {
    throw new Error("Impossible d'implémenter cette méthode.");
  }

  public void operationB() {
    throw new Error("Impossible d'implémenter cette méthode.");
  }

  public void operationC() {
    //Code
  }
}

class D implements I_Exemple {
  public void operationGlobale() {
    //Code...
  }

  public void operationA() {
    throw new Error("Impossible d'implémenter cette méthode.");
  }

  public void operationB() {
    //Code
  }

  public void operationC() {
    //Code
  }
}

Tout cela peut être refactoré bien plus élégamment ainsi :

interface I_Exemple {
  void operationGlobale();
}

interface I_A extends I_Exemple {
  void operationA();
}

interface I_B extends I_Exemple {
  void operationB();
}

interface I_C extends I_Exemple {
  void operationC();
}

class A implements I_A {
  public void operationGlobale() {
    //Code...
  }

  public void operationA() {
    //Code...
  }
}

class B implements I_B {
  public void operationGlobale() {
    //Code...
  }

  public void operationB() {
    //Code...
  }
}

class C implements I_C {
  public void operationGlobale() {
    //Code...
  }

  public void operationC() {
    //Code...
  }
}

class D implements I_B, I_C {
  public void operationGlobale() {
    //Code...
  }

  public void operationB() {
    //Code
  }

  public void operationC() {
    //Code
  }  
}

Comme vous le constatez, plus aucune classe n’est forcée à implémenter des méthodes qu’elle ne peut pas définir, tout en conservant ses spécificités. Plus aucune erreur n’a besoin d’être levée.

Bref, cela est en partie un mix entre le principe de responsabilité unique et une visualisation hiérarchique du problème. On note quand même le cas intéressant de la classe D qui permet à la fois d’avoir le type I_Exemple, I_B et I_C !

Principe d’inversion des dépendances (Dependency inversion)

Enfin, il reste le principe d’inversion des dépendances. Ce principe dit que :

• Les différentes classes ne doivent pas dépendre d’implémentations concrètes, mais d’abstractions (classes abstraites/interfaces).

• Les abstractions ne doivent pas dépendre des détails (les implémentations, les classes filles) mais les détails (les classes concrètes) doivent dépendre des abstractions. Nous l’avons bien vu avec l’exercice sur les pokémons lorsque nous étudions le principe ouvert/fermé.

Ce principe permet d’obtenir une très forte modularité du programme. Si on couple cela avec la technique d’injection des dépendances et des design patterns créateurs, tels que des fabriques abstraites, ou bien des conteneurs de dépendances, on obtient un logiciel dont on peut moduler le fonctionnement sans toucher au code source, simplement en ajoutant de nouvelles classes et/ou en éditant des fichiers de configuration. Les différents frameworks mettent en place une architecture favorisant l’inversion des dépendances.

En fait, ce principe découle de la bonne application des autres principes et notamment du principe ouvert/fermé et de la substitution de Liskov.

Nous verrons aussi qu’il est essentiel de bien respecter ce principe quand on réalise des tests unitaires.

Tout d’abord, illustrons ce principe avec un exemple.

Le problème souligné ici est qu’on a utilisé une classe concrète (Etudiant) à la place d’une classe abstraite ou d’une interface, ce qui empêche son utilisation pour d’autres types de classes (ici, Enseignant).

Illustrons ce problème avec un exemple :

class A {

  public void methodeA() {
    //Code...
  }

}

class B {

  public void methodeB() {
    //Code
  }

}

class Service {

  private A dependance;

  public Service() {
    dependance = new A();
  }

  public void action() {
    a.methodeA();
  }
}

Ici, nous avons un problème similaire : la classe Service dépend directement d’une implémentation concrète A ce qui le rend peu modulable. Si je veux utiliser B à la place de A, je dois récrire le code source de Service.

Pour régler cela, nous allons tout d’abord commencer par définir et utiliser une interface :

interface I_Exemple {
  void methodeExemple();
}

class A implements I_Exemple {

  public void methodeA() {
    //Code...
  }

  @Override
  public void methodeExemple() {
    methodeA();
  }

}

class B implements I_Exemple {

  public void methodeB() {
    //Code
  }

  @Override
  public void methodeExemple() {
    methodeB();
  }
}

Bien, je peux maintenant utiliser un I_Exemple dans Service au lieu de A ou B… Mais il reste un problème ! Dans l’exemple d’origine, A était instancié dans le constructeur. Hors, on ne peut pas instancier une interface ou une classe abstraite (seulement une classe concrète) :

class Service {

  private I_Exemple dependance;

  public Service() {
    dependance = new ???;
  }

  public void action() {
    dependance.methodeExemple();
  }
}

Pour palier à ce problème, on utilise l’injection de dépendance. La classe concrète est injectée via le constructeur, au moment de l’instanciation de l’objet, mais la classe ne connait que le type abstrait. Cela permet une modularité de la classe qui peut alors être utilisée avec n’importe quel service concret dérivé du type abstrait. Et on peut en ajouter dans le futur. C’est exactement ce que nous avions fait avec le paquet de cartes et les tris avec le pattern stratégie, mais également avec le décorateur dans l’exercice avec les produits. L’injection de dépendance est partout !

class Service {

  private I_Exemple dependance;

  public Service(I_Exemple dependance) {
    this.dependance = dependance;
  }

  public void action() {
    dependance.methodeExemple();
  }
}

class Main {

  public static void main(String[] args) {
    //Utilise "methodeA" dans "action"
    Service s1 = new Service(new A());

    //Utilise "methodeB" dans "action"
    Service s2 = new Service(new B());
  }

}

De cette manière, l’inversion des dépendances est respectée. La classe Service ne dépend plus d’aucun service concret, mais d’abstractions.

Pour finir, nous allons travailler sur un exercice un poil plus conséquent divisé en différentes couches (cf. partie architecture logicielle du cours sur les DSI).

Vous allez voir qu’en plus de rendre notre projet modulable, utiliser l’inversion de dépendances et globalement ne pas dépendre d’implémentations concrètes est plus qu’important, car une architecture ne respectant pas ce principe peut occasionner des effets de bords indésirables lors des tests unitaires.

Comme dans l’exercice précédent, l’architecture proposée ne respecte pas le principe d’inversion des dépendances, car la classe ServiceUtilisateur possède des dépendances vers des classes concrètes qui, de plus, ne sont pas injectées.

On se rend compte que cela pose un véritable problème au niveau des tests unitaire. Un test unitaire, comme son nom l’indique, teste le fonctionnement d’une classe, une unité. Or, quand on exécute les tests sur ServiceUtilisateur, les méthodes des dépendances concrètes utilisées sont aussi appelées ! Ce qui déclenche donc réellement l’enregistrement de l’utilisateur créé pour les tests dans la base de donnée, alors qu’on souhaitait simplement vérifier la méthode creerUtilisateur. Quand les tests sont exécutés une seconde fois, une erreur est détectée, car l’utilisateur existe déjà.

Imaginez-vous dans un contexte plus concret, par exemple, dans un projet web : avec une telle conception, vos tests unitaires déclencheraient l’enregistrement d’utilisateurs de test sur votre base de données réelle ! Ce n’est pas envisageable.

Les tests unitaires ne doivent pas dépendre de l’environnement de production. Ils doivent pouvoir être lancé seulement à partir du code de la classe testée, sans dépendre de rien d’autre.

Vous avez sans doute constaté des messages mail envoyé lors de l’exécution des tests unitaires. Bien sûr, cela n’est pas vraiment le cas, mais de même, dans un cas concret, avec la conception actuelle, des mails seraient véritablement envoyés lors du test du programme (après création d’un utilisateur). C’est problématique.

Pour palier à cela, les testeurs mettent en place des stubs. Il s’agit de classes bouchons qui ne réalisent pas vraiment l’action demandée, ou alors pas de manière persistante. Aucun effet de bord est produit.

Plus tard, dans l’année, vous découvrirez les mocks qui permettent de créer de “fausses” classes destinées aux tests dont on peut facilement éditer les méthodes.

Ici, la classe StockageUtilisateurMemoire agit comme un stub qu’on peut utiliser pour les tests sans risque. Dans un environnement réel, on utiliserait un stockage avec une base de données dédiée aux tests, comme SQLite, qu’on viderait ensuite.

Cependant, comment faire pour garder le stockage avec fichier pur l’exécution “normale” du programme, et le stockage en mémoire pour les tests ? Devons-nous éditer le code source de la classe ServiceUtilisateur avant les tests, puis la remettre en ordre ensuite ? Bien sûr que non ! Il suffit de mettre en pratique le principe d’inversion de dépendance que vous connaissez.

Il reste maintenant le problème des “mails envoyés” quand on exécute les tests. On aimerait également que plusieurs autres dépendances soient modulables dans le programme :

• L’envoi des mails. On veut pouvoir utiliser une autre classe et surtout une classe n’envoyant rien (un “Fake mailer”) pour les tests.

• Le système de hachage du mot de passe. On veut pouvoir changer entre MD5 et SHA256. Et pour économiser du temps de calcul pour les tests, on voudrait un “Fake Hasher” qui ne hache rien et renvoie le mot de passe en clair.

• La classe ServiceUtilisateur elle-même, qui doit pouvoir être remplacée par autre chose dans le ControllerUtilisateur. Cela pourrait notamment être utile si on veut tester le controller indépendamment du code de ServiceUtilisateur.

Conclusion

Voilà, maintenant, vous savez tout des principes SOLID ! Vous êtes donc plus proche d’un ingénieur logiciel qu’un codeur. Il existe un acronyme opposé : les principes STUPID qui sont 6 pratiques qui rendent le code très peu qualitatif, untestable, non évolutif et qu’il faut donc absolument éviter ! Bref, des mauvaises pratiques qui sont souvent observées. Vous pouvez consulter de la documentation à ce propos sur cette page.

Dorénavant, pour vos futurs projets (ou ceux actuels, comme la SAE) il faut systématiquement vous poser et réfléchir à la conception de votre programme à long terme. Il n’est jamais trop tard pour faire du refactoring, mais ne pas avoir besoin d’en faire en respectant une certaine qualité logicielle d’entrée de jeu est encore mieux.

Dans les prochains TPs, nous allons donc nous concentrer sur les design patterns (nous en avons déjà vu deux dans ce TP) qui permettront de vous donner des outils pour résoudre des problèmes de conception connus tout en mettant en facilitant le respect et la mise en ouvre les principes SOLID.