Le propos de ce cours est le bon design logiciel d’un point de vue orienté objet. Qu’est-ce que cela signifie? Voici un ensemble de principes caractéristiques d’un «bon design orienté objet.» Gardez ces principes à porté de main, nous les revisiterons à plusieurs reprises pendant la session.
Ne vous répétez pas (Don’t Repeat Yourself [DRY])
Chaque morceau d’information dans le système devrait n’avoir qu’une seule représentation ayant autorité et qui n’est pas ambigüe.
— Andy Hunt et Dave Thomas, The Pragmatic Programmer
Responsabilité Unique
Chaque classe devrait n’avoir qu’une seule responsabilité et cette responsabilité devrait être complètement encapsulée par la classe. Tous ses services devraient être étroitement liés avec cette responsabilité. (Étroitement lié à la cohésion forte.)
— Robert C. Martin, Principles of Object-Oriented Design
Ouvert/Fermé
Les entités logiciels (classes, modules, fonctions, etc.) devrait être ouvertes pour les extensions, mais fermé aux modifications.
— Bertrand Meyer, Object-oriented Software Construction
Substitution de Liskov
Si S est un sous-type de T, les objets de type S peuvent remplacés les objets de type T sans modifier aucune des propriétés désirable du programme.
— Barbara Liskov, Data abstraction and hierarchy
Séparation des Interfaces
Un client ne devrait pas être obligé de dépendre de méthodes qu’il n’utilise pas. (Étroitement lié au couplage faible).
— Robert C. Martin, Agile Software Development