Practical Object-Oriented Design in Ruby

Pourquoi la conception compte — le vrai coût du changement, considérer le logiciel comme un ensemble d'objets échangeant des messages, et la conception comme l'art de gérer les dépendances.

Faire en sorte qu'une classe ne fasse qu'une seule chose — le SRP, le test TRUE, cacher les variables d'instance derrière des méthodes et isoler les structures de données pour que le changement reste peu coûteux.

Reconnaître, isoler et inverser les dépendances — injection de dépendances, dépendre d'abstractions, et choisir la direction que les dépendances devraient pointer.

Concevoir les messages entre objets — interfaces publiques vs privées, demander le « quoi » et non le « comment », l'indépendance au contexte et la loi de Déméter.

Des interfaces inter-classes définies par le comportement, et non par la classe — reconnaître les canards cachés derrière les vérifications case-sur-classe et responds_to?, et faire confiance aux objets par ce qu'ils font.

L'héritage classique bien fait — reconnaître où il s'applique, refactoriser des classes concrètes en une superclasse abstraite, et utiliser le patron méthode gabarit (template method) avec des hooks plutôt que super.

Partager du comportement entre des classes sans lien de parenté grâce aux modules Ruby — reconnaître les rôles, écrire du code de module héritable, comprendre la recherche de méthode et les règles d'un héritage bien conçu (Liskov, hooks, hiérarchies peu profondes).

Construire des objets à partir de parties — composition vs inheritance, la relation has-a, modéliser avec factory et roles, et comment choisir entre inheritance, modules et composition.

Écrire des tests qui se paient d'eux-mêmes — quoi tester, quand tester, comment tester les messages entrants et sortants, et garder la suite de tests peu coûteuse à maintenir à mesure que la conception évolue.