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

Dans la première partie de cette ressource, nous avons parlé de conception logicielle et notamment de la manière de la représenter à l’aide de diagrammes de classes de conception.

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 de qualité du développement visent à faciliter l’évolution du logiciel tout en permettant de satisfaire 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 voire 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 proposent des structures et des mécanismes qui s’appuient souvent sur différents design patterns. Ils peuvent guider les choix de conception et faciliter l’application de bonnes pratiques, sans garantir à eux seuls la qualité du logiciel. Nous étudierons 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

L’acronyme SOLID désigne cinq principes de conception logicielle :

• Le principe de responsabilité unique (Single responsibility)

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

• 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 favorise le faible couplage et la forte cohésion des classes, facilite l’évolution du logiciel et réduit les risques de bugs liés à son architecture.

Les design patterns sont des solutions à des problèmes bien définis qui fournissent des modèles réutilisables et adaptables à de nombreux projets. Ces patterns contribuent notamment à mieux respecter les principes SOLID. En revanche, utiliser des design patterns ne garantit pas toujours une qualité de code respectant SOLID et peut même être contre-productif — il faut donc savoir les utiliser au bon endroit et au bon moment.

Une conception adaptée permet de prendre en charge certaines évolutions en ajoutant de nouvelles implémentations, sans modifier les classes qui utilisent les abstractions existantes. C’est, par exemple, l’objectif du principe ouvert/fermé : prévoir des possibilités d’extension tout en limitant les modifications du code déjà en place. Cela ne signifie pas que les classes existantes ne devront plus jamais être modifiées.

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 comment les principes SOLID permettent de traiter ces problèmes, et vous allez donc devoir refactorer les différentes applications. Refactorer du code (ou réusiner du code en français) consiste à améliorer sa structure interne sans changer son comportement observable. Il s’agit de rendre le code plus facile à comprendre et à faire évoluer.

Attention : Dans plusieurs exercices, il vous sera demandé de générer un diagramme de classes (avec IntelliJ ou autre IDE qui propose cette fonctionnalité). Bien que les diagrammes générés puissent être parfois légèrement erronés, et qu’il vaut généralement mieux faire le dessin soi-même, cela vous fera gagner du temps. Il est fortement conseillé de prendre des captures d’écran de chaque diagramme de classes et de les sauvegarder dans un sous-dossier de votre dépôt. Certains diagrammes permettent de comparer l’évolution de l’architecture et des dépendances avant/après refactoring.

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

Principe de responsabilité unique (Single Responsibility)

Pour mener à bien le déroulement d’une fonctionnalité, le programme va faire appel à diverses classes qui vont interagir entre elles. Ces classes vont traiter la demande. Chaque classe possède la responsabilité d’effectuer 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é regroupe des éléments de code qui évoluent pour les mêmes raisons. Deux traitements peuvent utiliser les mêmes données tout en relevant de responsabilités différentes.

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;}

   public String getContenu() {return contenu;}

}

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 a 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. Dans un logiciel plus complet, on aurait différents paquetages avec différents rôles : IHM, contrôleurs, 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éthodes, 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 (et donc assez peu concret), 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/Closed)

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 ouvertes aux extensions, mais fermées aux modifications.” (Bertrand 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 la qualité du 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 :

• Utilisation d’énormes blocs if/else if/else ou de blocs switch case qui grossissent 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 ou getClass() (pour vérifier le type de l’objet) et des conversions de type (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).
• Une classe mère qui dépend de ses classes filles.

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 ? Aussi, la classe Animal ne sera jamais finie, car il faudra en permanence modifier la méthode crier pour ajouter de nouveaux animaux. Elle n’est donc pas fermée aux modifications lorsqu’on veut étendre l’application à d’autres 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 50 dégâts, ou 70 s’il peut lancer un rayon de feu; 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éer 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.equals("rectangle")) {
         dessinerRectangle();
      }
      else if(typeFigure.equals("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, si typeFigure contient une chaîne différente de "rectangle" et de "triangle", la méthode ne dessine rien et ne signale pas cette valeur inconnue.

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 typeFigure 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 une nouvelle classe et l’implémentation de sa méthode dessiner. Les classes qui manipulent les figures à travers le type FigureGeometrique peuvent utiliser cette nouvelle figure sans être modifiées. Le code qui construit les objets, par exemple le Main, peut en revanche devoir être adapté pour instancier cette nouvelle classe. On ne peut plus sélectionner un type de figure inconnu à l’aide d’une simple chaîne de caractères.

Ici, FigureGeometrique ne contient aucun état et définit uniquement une méthode abstraite : une interface convient donc bien pour représenter ce contrat commun. Une classe abstraite devient notamment utile si l’on souhaite factoriser des attributs ou une implémentation commune à plusieurs sous-classes.

Si vous bloquiez, ceci devrait vous permettre de refactorer le code du paquetage fr.umontpellier.iut.ocp1 (animaux). Nous allons également refactorer ocp2 (pokémons). Cela peut sembler un peu plus compliqué (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 le cas sur le deuxième diagramme.

Nous allons maintenant tester votre compréhension des deux principes (S et O) avec un nouvel exercice un peu différent de ce que vous avez vu jusqu’ici, 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 trop de responsabilités : cela ne devrait pas être à elle de gérer les différents algorithmes de tri de 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é 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 un design pattern au niveau des tris (et des mélanges) : Stratégie. Ce pattern permet d’encapsuler un ensemble de comportements (algorithmes de tris) dans des classes et de rendre ces algorithmes interchangeables dans une classe cliente (Paquet). Ainsi, le comportement spécifique est injecté dans la classe cliente sans modifier le code source de celle-ci. Ce pattern s’appuie sur ouvert/fermé, l’inversion des dépendances et aide à respecter le principe de 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 générer, vous devriez pouvoir reconnaître les éléments du pattern stratégie et le réutiliser lorsqu’un objet doit pouvoir changer d’algorithme.

Héritage, composition et principe ouvert-fermé

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 compliqué d’avoir un même produit possédant ces deux fonctionnalités à la fois, notamment, car le multihéritage de classes n’est pas possible en Java.

Peut-être que vous avez été plus malin et que vous avez pensé à implémenter une classe héritant de Produit et implémentant les deux comportements. Mais dans ce cas, il y a de la duplication de code.

Ou alors, peut-être que vous avez été encore plus malin et que vous avez pensé à faire une classe composée de deux instances des types de produit concernés. C’est déjà beaucoup mieux ! Mais que se passe-t-il si d’autres types de produit sont ajoutés ? Par exemple, si on a cinq types de produits différents et qu’on veut mixer au choix certaines fonctionnalités de certains types ? La classe composée sera de plus en plus difficile à gérer et ne sera jamais fermée aux modifications.

Tout en respectant le principe ouvert/fermé, il existe une méthode générale pour construire un Produit possédant autant de comportements mixtes que nous souhaitons. Si de nouveaux comportements sont ajoutés dans le futur, il n’y aura pas de modification du code existant. On peut implémenter un tel système en favorisant la composition au lieu d’un héritage.

Pour résoudre le problème présenté dans cet exercice, l’idée est la suivante :

• Une abstraction commune, notée I, typiquement une interface, définit les opérations que les objets de base et les décorateurs doivent proposer.

• Une classe de base implémente cette abstraction. Chaque classe de décorateur implémente également I et possède un attribut référençant un autre objet de type I. Le décorateur délègue une partie des opérations à cet objet et y ajoute son propre comportement.

• Un décorateur peut envelopper un objet de base ou un autre décorateur. On peut donc imbriquer plusieurs décorateurs pour combiner leurs comportements.

Illustrons cela à travers un exemple :

class Salarie {

   private double salaire;

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

   public double getSalaire() {
      return salaire;
   }

}

class SalarieChefDeProjet extends Salarie {

   private int nombreProjetsGeres;

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

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

}

class SalarieResponsableDeStagiaires extends Salarie {

   private int nombreStagiairesGeres;

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

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

Ici, nous retrouvons le même problème que pour les produits : cette hiérarchie ne permet pas de combiner simplement les responsabilités de chef de projet et de responsable de stagiaires sans ajouter des sous-classes pour les différentes combinaisons.

Cette hiérarchie représente séparément les différents rôles, mais ne permet pas de les combiner facilement. Nous pouvons utiliser la composition pour construire des objets qui enveloppent d’autres objets et cumulent ainsi leurs comportements.

interface SalarieInterface {
  double getSalaire();
}


class Salarie implements SalarieInterface {

  private double salaire;

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

  public double getSalaire() {
    return salaire;
  }

}

class SalarieChefProjet implements SalarieInterface {

  private SalarieInterface salarie;

  private int nombreProjetsGeres;

  public SalarieChefProjet(SalarieInterface salarie, int nombreProjetsGeres) {
    this.salarie = salarie;
    this.nombreProjetsGeres = nombreProjetsGeres;
  }

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

}

class SalarieResponsableDeStagiaires implements SalarieInterface {

  private SalarieInterface salarie;

  private int nombreStagiairesGeres;

  public SalarieResponsableDeStagiaires(SalarieInterface salarie, int nombreStagiairesGeres) {
    this.salarie = salarie;
    this.nombreStagiairesGeres = nombreStagiairesGeres;
  }

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

Avec cette nouvelle architecture, nous pouvons ajouter à des instances de salariés des responsabilités de chef de projet et/ou de responsables de stagiaires :

//Un salarié (qui existe déjà et qui est utilisé dans l'application...)
Salarie salarie = new Salarie(2000);

//Salarie qui est chef de projet gérant 3 projets
SalarieInterface salarieChef = new SalarieChefProjet(salarie, 3);
salarieChef.getSalaire(); //Renvoie 2300

//Salarie qui est responsable de stagiaires gérant 5 stagiaires
SalarieInterface salarieResponsableDeStagiaires = new SalarieResponsableDeStagiaires(salarie, 5);
salarieResponsableDeStagiaires.getSalaire(); //Renvoie 2250

//Salarié qui est chef de projet gérant 3 projets et aussi responsable de stagiaires gérant 5 stagiaires
SalarieInterface salarieAvecMultiResponsabilites = new SalarieResponsableDeStagiaires(new SalarieChefProjet(salarie, 3), 5);
salarieAvecMultiResponsabilites.getSalaire(); //Renvoie 2550

Le type de l’attribut qui référence l’objet enveloppé est SalarieInterface, et non Salarie. Ainsi, cet attribut peut référencer aussi bien un salarié de base qu’un autre décorateur, ce qui permet de combiner SalarieChefProjet et SalarieResponsableDeStagiaires.

L’objet enveloppé est fourni au constructeur du décorateur : la dépendance est injectée, comme dans l’exercice sur le paquet de cartes et les méthodes de tri. Cela permet de décorer un objet existant et de choisir les décorateurs à combiner. Cette injection ne détermine pas, à elle seule, la notation UML de la relation.

Attention, dans cet exemple précis, 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 d’imbrication des objets, à cause de la méthode de calcul du prix du produit avec une réduction. Si la méthode de calcul avait été un pourcentage pour ce type de produit (-X% du prix) comme pour le produit avec une date de péremption proche, l’ordre n’aurait pas eu d’importance. Bref, cela est à prendre en compte quand vous concevez et que vous utilisez ce type de solution.

Tout fonctionne, mais le code est encore un peu redondant : chaque décorateur possède un attribut référençant un objet du type de l’interface commune aux produits et un constructeur pour initialiser cet attribut.

Concernant l’exemple des salariés, nous pourrions factoriser le code ainsi :

//Nous reviendrons sur le nom "décorateur" plus tard.
abstract class SalarieDecorateur implements SalarieInterface {
   private SalarieInterface salarie;

   public SalarieDecorateur(SalarieInterface salarie) {
      this.salarie = salarie;
   }

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

class SalarieChefProjet extends SalarieDecorateur {

  private int nombreProjetsGeres;

  public SalarieChefProjet(SalarieInterface salarie, int nombreProjetsGeres) {
    super(salarie);
    this.nombreProjetsGeres = nombreProjetsGeres;
  }

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

}

class SalarieResponsableDeStagiaires extends SalarieDecorateur {

  private int nombreStagiairesGeres;

  public SalarieResponsableDeStagiaires(SalarieInterface salarie, int nombreStagiairesGeres) {
    super(salarie);
    this.nombreStagiairesGeres = nombreStagiairesGeres;
  }

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

}

class Main {
    public static void main(String[]args) {
        SalarieInterface s1 = new Salarie(2000);
        SalarieInterface s2 = new SalarieChefProjet(s1, 3);
        SalarieInterface s3 = new SalarieResponsableDeStagiaires(s1, 2);
        SalarieInterface s4 = new SalarieChefProjet(new SalarieResponsableDeStagiaires(s1, 4), 3);

        //Affiche 2000
        System.out.println(s1.getSalaire());

        //Affiche 2300
        System.out.println(s2.getSalaire());

        //Affiche 2100
        System.out.println(s3.getSalaire());

        //Affiche 2500
        System.out.println(s4.getSalaire());
    }
}

Si nous ajoutons un nouveau comportement à un produit, il suffira de créer une nouvelle classe de décorateur qui étend la classe abstraite. Cette architecture utilise la composition pour combiner les comportements et l’héritage pour factoriser le code commun aux décorateurs. L’ajout d’un décorateur ne nécessite pas de modifier les classes existantes.

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.

Attention : le décorateur est un pattern différent de builder que vous avez vu l’an dernier.

Un builder facilite la construction d’un objet complexe, notamment lorsque celui-ci possède de nombreux paramètres, dont certains sont optionnels.

Le pattern décorateur permet d’ajouter des comportements à un objet en l’enveloppant dans un autre objet qui respecte la même abstraction. Plusieurs décorateurs peuvent être imbriqués pour cumuler leurs effets.

Les nouvelles fonctionnalités sont accessibles en passant par le décorateur. Une partie du programme qui conserve une référence vers l’objet d’origine continue à utiliser son comportement initial. Pour bénéficier des nouveaux comportements, elle doit utiliser la référence vers l’objet décoré.

De nouveaux comportements peuvent ainsi être développés dans de nouvelles classes de décorateurs, sans modifier la classe de l’objet d’origine. Le décorateur est donc un pattern structurel qui permet de combiner des comportements autour d’un objet.

À partir du diagramme de classes que vous avez généré, vous devriez pouvoir identifier les éléments du pattern décorateur et le réutiliser pour combiner des comportements autour d’un objet.

Afin de vérifier que vous avez bien compris le principe du pattern décorateur, nous allons faire un dernier exercice en relation.

On considère la librairie jeu-equipe-monstres-1.0.0.jar importée dans votre projet. C’est une librairie avec du code externe compilé. Vous pouvez utiliser ses classes, mais vous ne pouvez donc pas modifier le code source de ces dernières (vu que le code ne vous appartient pas).

Voici le diagramme de classes de la librairie :

Cette librairie est utilisée dans le cadre d’un mini-jeu vidéo où un joueur peut avoir une équipe (collection) de monstres. Pour chaque monstre, il est possible de calculer leur force. Chaque type de monstre applique un algorithme différent pour calculer sa force, en fonction de ses attributs. Pour l’instant, il y a deux types de monstres dans la librairie : le slime et le chocobo. Le joueur peut ensuite présenter son équipe de monstre.

Principe de substitution de Liskov (Liskov substitution)

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 pour lequel 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 réellement une spécialisation.

Tout cela occasionne parfois des problèmes inattendus qui sont mis en lumière par le principe de substitution de Liskov qui est fortement lié à la notion de programmation par contrat.

Quand on parle de programmation par contrat cela signifie que chaque classe possède un ensemble de règles (implicites ou explicites) autour de ses méthodes : pré-conditions, post-conditions, effets de bord, etc. Globalement, quelqu’un qui utilise une instance d’une classe donnée sait à quoi s’attendre quand on appelle telle ou telle méthode. Par exemple, le contrat de ArrayList précise qu’un appel réussi à add(element) ajoute cet élément à la fin de la liste.

Le principe de substitution de Liskov, introduit par Barbara Liskov, énonce qu’un objet d’un sous-type doit pouvoir être utilisé partout où un objet du type de base est attendu, sans rompre le contrat de ce type de base. Une méthode redéfinie dans une sous-classe doit donc préserver les garanties promises par la superclasse.

Par exemple, si une classe MonArrayList étend ArrayList et redéfinit add(element), elle doit conserver le contrat de cette opération : après un appel réussi, l’élément ajouté se trouve à la fin de la liste. L’implémentation peut être différente, mais un code qui utilise ArrayList doit continuer à fonctionner avec une instance de MonArrayList, conformément au contrat de ArrayList. Les tests portant sur ce contrat doivent donc continuer à passer lorsque l’on remplace une instance de ArrayList par une instance de MonArrayList.

L’utilisation inappropriée de l’héritage peut amener au non-respect de ce principe.

Voici un scénario illustrant plus en détail 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 un sous-type de rectangle, non ?

Avec cette modification, le principe de substitution de Liskov n’est plus respecté ! On a cassé le contrat de Rectangle dans Carre. Carre est un Rectangle et on devrait pouvoir modifier sa hauteur et sa largeur librement !

De plus, 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.

Une autre mauvaise solution possible serait d’ajouter une fonction setTailleCote dans Carre et de redéfinir les fonctions setHauteur et setLargeur dans Carre 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 toujours pas utiliser Carre comme un Rectangle (on ne respecte toujours pas LSP) 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 !

Dans cette modélisation, faire hériter Carre de Rectangle pose donc problème : le contrat de Rectangle permet de modifier ses deux dimensions indépendamment, ce qui est incompatible avec les propriétés d’un carré. Un carré reste bien un rectangle en géométrie, mais cette relation mathématique ne suffit pas à justifier un héritage entre nos classes : il faut aussi que leurs comportements soient compatibles.

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 à la place, ce qui nous éviterait de gérer les méthodes indésirables de changement de hauteur ou largeur imposées par héritage.

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

La composition forte entre Carre et Rectangle exprime ici que chaque Carre possède son propre Rectangle, utilisé comme détail interne de son fonctionnement. Ce rectangle n’est pas partagé et sa référence n’est pas exposée à l’extérieur (d’où la composition forte). Elle est en opposition avec la composition faible, qui indique aussi une composition, mais dans laquelle la dépendance peut être partagée avec d’autres objets (elle n’est pas “piégée” dans la classe). Par exemple, un cas où une dépendance est injectée via le constructeur est un cas de composition faible (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.

Les derniers tests ne sont pas mal rédigés, car, comme Pile hérite de Vector, cette classe doit respecter le contrat imposé par sa classe mère. Ces tests vérifient qu’il est bien possible de substituer un Vector par une Pile dans des algorithmes qui acceptent un Vector en paramètre. De plus, comme Vector implémente (par héritage) l’interface List qui étend elle-même l’interface Collection : on doit pouvoir substituer un objet de type List ou Collection par un objet de type Pile dans les fonctions et méthodes de Java qui prennent des collections ou des listes en paramètre, tout en conservant un comportement cohérent (donc, sans casser le contrat de Vector, des classes héritées et des interfaces implémentées).

Comme ces tests passent, on peut donc à priori en conclure que Pile respecte bien le contrat de Vector… Logique : nous n’avons redéfini aucune méthode de Vector, il y a donc peu de chances de casser quoi que ce soit !

Nous souhaitons cependant que l’interface publique de Pile se limite aux opérations estVide, empiler, depiler et sommetPile. Or, comme Pile hérite de Vector, toutes les opérations publiques d’une liste restent accessibles : on peut notamment insérer ou supprimer un élément ailleurs qu’au sommet. Cette classe respecte encore le contrat de Vector, mais elle n’impose pas l’usage LIFO attendu dans cet exercice.

Pour résoudre ce problème, on pourrait alors redéfinir toutes les méthodes de Vector (qui nous gênent) pour qu’elles ne fassent rien, afin de respecter le contrat de Pile. Par exemple, celles-ci :

public class Pile<T> extends Vector<T> {

    @Override
    public synchronized Iterator<T> iterator() {
        return null;
    }

    @Override
    public synchronized T get(int index) {
        return null;
    }

    @Override
    public boolean remove(Object o) {
        return false;
    }

    @Override
    public synchronized T remove(int index) {
        return null;
    }

    @Override
    public void add(int index, T element) {}

    //Etc...
}

Mais le principe de substitution de Liskov ne serait alors plus respecté, car on casserait le contrat de Vector ! On ne pourrait pas substituer un Vector par une Pile et les quatre derniers tests (dans la classe PileTest du paquetage fr.umontpellier.iut.lsp2 dans src/test/java) ne fonctionneraient plus…

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 et ainsi éviter un certain degré de duplication de code.

L’héritage de Stack vers Vector expose des opérations qui permettent de contourner le fonctionnement attendu d’une pile (voir documentation). Cette classe est conservée notamment pour assurer la compatibilité avec les programmes existants. 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.

Les clients d’une interface ne devraient pas dépendre de méthodes qu’ils n’utilisent pas. On préfère donc plusieurs interfaces ciblées, correspondant à des besoins ou à des capacités précis, à une interface qui regroupe des opérations sans rapport pour ses différents clients.

Une interface définit un contrat. Une classe concrète doit fournir ou hériter d’une implémentation de ses méthodes abstraites. Si certaines de ces opérations n’ont aucun sens pour cette classe, cela peut révéler que l’interface regroupe trop de responsabilités.

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’exceptions pour des opérations sans signification indique une très mauvaise conception.

Le problème vient du regroupement, dans une seule interface, des opérations communes à toutes les montures et de celles qui correspondent à des capacités particulières. Monture peut conserver les calculs de vitesse et de durée d’un trajet, communs à toutes les montures. Le calcul de l’endurance terrestre, celui du temps maximum de vol et celui de la puissance de feu peuvent être décrits dans des interfaces distinctes. Chaque classe implémente alors les interfaces correspondant à ses capacités. Une nouvelle classe peut réutiliser les interfaces existantes. Le nom reste accessible par la classe Creature.

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 UnsupportedOperationException("Impossible d'implémenter cette méthode.");
  }

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

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

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

  public void operationB() {
    //Code
  }

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

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

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

  public void operationB() {
    throw new UnsupportedOperationException("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 UnsupportedOperationException("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 exception signalant une opération non prise en charge 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 modules de haut niveau, qui portent les règles métier, ne doivent pas dépendre directement des modules de bas niveau, qui réalisent les détails techniques. Les deux doivent dépendre d’abstractions.

• Les abstractions doivent décrire les opérations attendues sans dépendre des détails de leur réalisation. Les implémentations concrètes doivent se conformer à ces abstractions.

Cela ne signifie pas qu’il faut créer une interface pour chaque classe utilisée. On cherche surtout à isoler le code métier des détails techniques que l’on souhaite pouvoir remplacer ou faire évoluer indépendamment.

L’injection de dépendances permet de fournir aux objets les implémentations qu’ils utilisent. Le choix et l’assemblage de ces implémentations peuvent être regroupés dans un point d’entrée, dans des fabriques ou dans un conteneur de dépendances. On peut ainsi remplacer une implémentation sans modifier les modules qui l’utilisent. On obtient ainsi des logiciels 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.

Ce principe complète les autres principes SOLID. Dépendre d’abstractions facilite l’ajout de nouvelles implémentations sans modifier leurs clients, conformément au principe ouvert/fermé. Ces implémentations doivent respecter le contrat de l’abstraction, conformément au principe de 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é dans cet exercice est que CompteUniversitaire dépend directement de la classe concrète Etudiant et l’instancie dans son constructeur. Son détenteur est donc nécessairement représenté par un Etudiant, même si les informations fournies sont celles d’un enseignant. Il faudrait pouvoir manipuler le détenteur à travers une abstraction commune aux étudiants et aux enseignants.

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() {
    dependance.methodeA();
  }
}

Ici, nous avons un problème similaire : la classe Service dépend directement d’une implémentation concrète A, ce qui la 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. Or, on ne peut pas instancier une interface ou une classe abstraite (seulement une classe concrète). Et on ne peut pas spécifier directement quelle classe concrète est utilisée, car notre classe Service ne sera alors plus modulable :

class Service {

  private I_Exemple dependance;

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

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

Pour pallier ce problème, on utilise ici l’injection de dépendances par constructeur. Une instance concrète de la dépendance est fournie au constructeur de Service depuis l’extérieur. La classe Service manipule cette instance à travers le type abstrait I_Exemple et peut ainsi utiliser différentes implémentations de cette interface. C’est ce que nous avons fait avec le paquet de cartes et les tris, avec le pattern stratégie, mais également avec le décorateur dans l’exercice des produits.

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) {
    // L'appel à action() utilise methodeA().
    Service s1 = new Service(new A());
    s1.action();

    // L'appel à action() utilise methodeB().
    Service s2 = new Service(new B());
    s2.action();
  }

}

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.

Exercices bilan

Dans cette section, vous allez travailler sur un ensemble d’exercices “bilan” qui reprennent les notions abordées dans ce TP. L’idée est que vous identifiez le problème et mettiez en place une solution adéquate et respectueuse des principes SOLID.

Villes et bâtiments

Comptes bancaires

Les classes Entreprise et Banque manipulent des objets de type CompteBancaire. Elles doivent donc pouvoir compter sur son contrat : des dépôts sans plafond et un nombre illimité de retraits, sous réserve d’un solde suffisant. Les opérations d’ajout de bénéfices et de paiement des salariés de Entreprise doivent fonctionner avec tout objet respectant ce contrat. Banque, quant à elle, se contente de gérer les références vers les comptes : elle n’a pas besoin des garanties particulières de CompteBancaire.

Serveurs à louer

Une application modulable

Pour finir, nous allons travailler sur un exercice un poil plus conséquent divisé en différentes couches.

Vous allez voir qu’isoler les règles métier des détails techniques et injecter les dépendances facilite les tests unitaires. On peut ainsi contrôler les collaborateurs utilisés par le code testé et éviter de déclencher des écritures persistantes ou des envois de mails pendant ces tests.

La classe ServiceUtilisateur dépend directement de détails techniques concrets et choisit elle-même leurs implémentations. Ces dépendances ne sont pas injectées, ce qui empêche de les remplacer facilement pour les tests.

Un test unitaire vérifie le comportement d’une unité de code, qui peut correspondre à une classe ou à un petit ensemble de classes. Ici, nous souhaitons tester ServiceUtilisateur sans dépendre d’un stockage persistant ni envoyer réellement des mails.

Avec le stockage dans un fichier, l’utilisateur créé lors d’une première exécution reste présent lors de la suivante. Le résultat du test dépend donc des exécutions précédentes. Nous souhaitons au contraire des tests isolés et reproductibles, qui retrouvent les mêmes conditions de départ à chaque exécution.

Pour cela, nous pouvons remplacer certaines dépendances par des doublures de test, c’est-à-dire des objets adaptés aux besoins des tests.

StockageUtilisateurMemoire constitue ici un fake : une implémentation fonctionnelle mais simplifiée du stockage. Elle modifie bien son état en mémoire ; nous utiliserons donc une nouvelle instance, initialement vide, pour chaque test.

Un stub fournit des réponses prédéfinies pour les besoins d’un scénario. Plus tard dans l’année, vous découvrirez aussi les mocks, qui permettent notamment de vérifier les appels effectués sur une dépendance.

Nous remplacerons ensuite l’envoi de mails par une doublure qui n’envoie aucun message réel.

Cependant, comment faire pour garder le stockage avec fichier pour 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 SHA-256. Pour tester la logique de ServiceUtilisateur indépendamment du calcul de hachage, on utilisera un FakeHasher qui renvoie simplement la chaîne reçue.

• 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 six pratiques qui rendent le code très peu qualitatif, intestable, 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.

Pour vos futurs projets, ou ceux déjà en cours comme la SAE, prenez le temps de réfléchir à la conception de votre programme et aux évolutions envisageables. Une bonne conception facilite les changements, mais n’élimine pas le besoin de refactoring : celui-ci permet de faire évoluer la structure du code à mesure que les besoins et votre compréhension du problème se précisent.

Dans les prochains TP, nous allons donc nous concentrer sur les design patterns (nous en avons déjà vu deux dans ce TP), qui vous fourniront des outils pour résoudre des problèmes de conception connus tout en facilitant l’application des principes SOLID.