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