EnglishCommencer

Les principes SOLID

Les cinq principes de conception objet (responsabilité unique, ouvert-fermé, substitution de Liskov, ségrégation des interfaces, inversion des dépendances) : les énoncer, reconnaître une violation et la corriger.

  • 28 cartes
  • 5 thèmes
  • Gratuit
Réviser ce deck

Le programme, thème par thème

Le poids de chaque thème suit celui que lui donne l'examen.

  1. Notions
  2. Questions
  3. Ranger et relier
  4. Mises en situation
  5. Comprendre

Quelques cartes du deck

  • SOLID : de quoi s'agit-il ?

    Voir la réponse

    Sigle qui regroupe cinq principes de conception objet visant un code facile à modifier : responsabilité unique, ouvert-fermé, substitution de Liskov, ségrégation des interfaces, inversion des dépendances.

    Ce sont des principes de conception, pas des règles du langage : le compilateur ne les vérifie pas, c'est la relecture et le coût des changements qui les révèlent.

  • On veut ajouter une forme Triangle. Quel principe cette méthode viole-t-elle ?

    ```java
    double aire(Forme f) {
    switch (f.type) {
    case CERCLE: return Math.PI * f.rayon * f.rayon;
    case CARRE: return f.cote * f.cote;
    default: throw new IllegalArgumentException();
    }
    }
    `

    • Ouvert-fermé
    • Responsabilité unique
    • Ségrégation des interfaces
    • Substitution de Liskov
    Voir la réponse

    Ouvert-fermé

    Chaque nouvelle forme oblige à rouvrir et modifier aire. La correction : une interface Forme avec une méthode aire() que chaque classe implémente.

  • Le principe ouvert-fermé demande qu'un module soit … à l'extension et … à la modification.

    Voir la réponse

    Le principe ouvert-fermé demande qu'un module soit ouvert à l'extension et fermé à la modification.

    Ouvert : on peut lui ajouter des comportements. Fermé : on n'a pas besoin d'en réécrire le code pour cela.

  • Responsabilité unique : de quoi s'agit-il ?

    Voir la réponse

    Principe selon lequel une classe ne doit avoir qu'une seule raison de changer : elle répond à un seul acteur ou à un seul sujet.

    Une classe Facture qui calcule, imprime et écrit en base change si la règle de calcul, le format d'impression ou la base évolue : trois raisons, donc trois classes.

  • Une interface Machine déclare imprimer(), scanner() et faxer(). L'imprimante simple doit tout implémenter et lève UnsupportedOperationException dans scanner() et faxer(). Quelle correction ?

    • Découper en Imprimante, Scanner et Fax : chaque classe n'implémente que les siennes
    • Laisser les corps vides au lieu de lever une exception
    • Faire hériter l'imprimante simple d'une imprimante complète
    • Ajouter à Machine une méthode estSupporte() à tester avant chaque appel
    Voir la réponse

    Découper en Imprimante, Scanner et Fax : chaque classe n'implémente que les siennes

    Des corps vides cachent la violation sans la résoudre, et l'héritage en ajoute une de plus. La méthode estSupporte() oblige chaque client à connaître des méthodes qui ne le concernent pas : seul le découpage supprime la dépendance inutile.

Réviser ce deck