POODR Chapitre 1 : La conception orientée objet

Vue d'ensemble

Le chapitre 1 pose le cadre de tout le livre. Sandi Metz soutient que la conception ne consiste pas à suivre des règles rigides ni à appliquer des patterns pour eux-mêmes — il s'agit d'organiser le code pour qu'il soit peu coûteux à changer aujourd'hui et demain. Le chapitre installe le vocabulaire et l'état d'esprit pour tout ce qui suit.

Pourquoi la conception compte

Un logiciel a deux missions : il doit fonctionner maintenant, et il doit être facile à changer plus tard. Le faire fonctionner est la partie évidente. La partie cachée et coûteuse, c'est le changement — les exigences évoluent, des fonctionnalités s'ajoutent, des bugs sont corrigés. L'essentiel du coût d'un logiciel intervient après la livraison de la première version.

Le problème, c'est que les applications faciles à écrire sont souvent difficiles à changer, et inversement. Les applications bien conçues absorbent le changement avec élégance ; les applications mal conçues deviennent progressivement de plus en plus coûteuses à toucher jusqu'à ce que, finalement, le coût du changement donne l'impression que le tout n'en vaut plus la peine.

La conception est l'art d'organiser le code.

Le coût du changement

Metz reformule la conception comme un problème économique. On veut que le coût actuel net de son logiciel — la construction plus tous les changements futurs — soit le plus bas possible. Deux modes d'échec vous coûtent cher :

• La sous-conception (aucune conception du tout) : le code devient un marécage de dépendances où chaque changement casse quelque chose d'inattendu.
• La sur-conception : on anticipe l'avenir avec des abstractions élaborées qui ne rapportent jamais, et cette complexité spéculative devient un obstacle.

L'objectif est une conception juste suffisante, appliquée lorsque le besoin est réel plutôt qu'imaginé.

Ce dont il est vraiment question dans la conception orientée objet

Une application orientée objet est composée d'objets qui s'envoient des messages les uns aux autres. L'insight surprenant : les messages sont en réalité plus importants que les objets. Ce qui compte n'est pas seulement ce que chaque objet sait et fait, mais la façon dont les objets se parlent.

Le problème, ce sont les dépendances. Lorsqu'un objet en sait trop sur un autre, ils s'entremêlent : changer l'un vous force à changer l'autre. Un objet unique avec trop de dépendances est fragile, et une toile d'objets trop connectés résiste à tout changement.

La conception orientée objet consiste, fondamentalement, à gérer les dépendances.

La conception est un ensemble de techniques pour organiser le code de sorte que les objets tolèrent le changement. Lorsque les dépendances sont maîtrisées, les objets peuvent évoluer indépendamment.

Les outils du métier : principes et patterns

Metz désigne deux corpus de connaissances qui nourrissent une bonne conception :

• Les principes — le plus célèbre étant SOLID :

  • Single Responsibility (responsabilité unique)
  • Open/Closed (ouvert/fermé)
  • Liskov Substitution (substitution de Liskov)
  • Interface Segregation (ségrégation des interfaces)
  • Dependency Inversion (inversion des dépendances)

  Auxquels s'ajoutent des idées complémentaires comme DRY (Don't Repeat Yourself) et la Law of Demeter. Ce sont des lignes directrices distillées et nommées, étayées par l'expérience et la recherche.

• Les patterns — les design patterns du Gang of Four : des solutions nommées et réutilisables à des problèmes courants. Les patterns sont précieux, mais seulement lorsqu'on les applique au problème pour lequel ils ont été conçus. Mal appliqués, les patterns font partie du problème.

Le reste du livre porte sur l'application pragmatique de ces idées, dans du vrai code Ruby.

Une brève note sur le modèle objet de Ruby

Le chapitre se termine par un bref rappel de ce que signifie « classe » en Ruby : les classes sont des plans pour les objets, les objets répondent aux messages, et tout (les nombres, les chaînes, nil) est un objet. La flexibilité de Ruby vous donne un grand pouvoir pour écrire du code magnifique — et un pouvoir tout aussi grand pour écrire un enchevêtrement inextricable. La conception est ce qui vous maintient du bon côté de cette ligne.

Points clés à retenir

1. Le but de la conception est de réduire le coût du changement — considérez-la comme une décision économique, pas comme un rituel.
2. Les applications sont des objets qui échangent des messages ; l'organisation de ces messages est la véritable conception.
3. Les dépendances sont l'ennemi — la conception orientée objet est la discipline de leur gestion.
4. La sous-conception comme la sur-conception vous coûtent cher — visez une conception « juste suffisante », guidée par des besoins réels.
5. Les principes (SOLID, DRY, Law of Demeter) et les patterns sont des outils, précieux seulement lorsqu'ils sont appliqués avec discernement.
6. Ruby vous donne de la liberté ; la conception est la façon d'empêcher cette liberté de devenir le chaos.

---

🌐 Traduit par Claude