🎯 Objectif ; mettre en place un découplage fort et éviter l'effet "boite à outils" Cas d'étude, l'anti-pattern  Un composant quelconque doit logger ses actions; l'anti-pattern pour  :  class Composant def initialize @log = open('composant.log', 'a') end def

Objectif : Les sous-classes doivent pouvoir remplacer leur classe de base sans changer le comportement attendu. Le Principe de Substitution de Liskov est l'un des cinq principes SOLID de la programmation orientée objet. Formulé par Barbara Liskov en 1987, il stipule que : "Si S est un sous-type de

Objectif : une classe ne doit pas être obligée d'implementer des méthodes dont elle n'a pas besoin (il existe undef en Ruby, mais au final cela reste une violation car c'est comme une redéfinition par une méthode vide). Anti-pattern class Command def perform raise NotImplementedError

Objectif : une classe ne doit avoir qu'une seule responsabilité et defacto qu'une seule motivation pour être modifiée Anti-pattern On image une collecte de news sur un fournisseur, puis sa valorisation/formatage et la possibilité de l'envoyer par SMS ou Mail : Class News def collect(

🎯 Objectif : lancer une/actions quand un traitement se déclenche suivant un caractère événementiel Anti-Pattern   class RecuperateurBoursier                  def initialize(code, limite_bas:, limite_haut: )       @limite_bas = limite_bas       @limite_haut = limite_haut       @code = code     end        def lancer       dernierevaleur = nil       loop do         valeur = Valeur.recuperer(@code)         print "Valeur courrante: #{valeur}\n&

🎯 Objectif : éviter encore une fois d'implémenter dans une même classe des fonctions qui ne lui sont pas intrinsèques. Anti-pattern  On créé une classe CompteBancaire qui intègre et implémente le contrôle d'accès class CompteBancaire       attr_reader :balance              def initialize(init_balance: , utilisateur: )           @utilisateur = utilisateur           @liste_utilisateurs = ['

🎯 Objectif :  Construire une classe en exploitant une partie d'un autre et la charge active de l'autre 👆 Remarque : cas d'une Queue LIFO  Anti-pattern Anti-pattern 1 : from scratch Construire from scratch, même pas en rêve Anti-pattern 2 : l'héritage class MyQueue < Array           alias :enq

🎯 Objectif : éviter de faire une classe "Boite à outil", cad qui fait plus que ce qu'elle doit, et qui intègre du code d'adaption et donc du savoir spécifique, on utilise le Design pattern Adapter pour limiter l'adaptation des inputs dans la classe

🎯 Objectif ; mettre en place un découplage fort et éviter l'effet "boite à outils" Cas d'étude, l'anti-pattern  Un composant quelconque doit logger ses actions; l'anti-pattern pour  :  class Composant        def initialize       @log = open('composant.log', 'a')     end        def