Category Archives: En français

Articles écrits en langue française

SOLID Partie V : Dependency Inversion Principle

En français, Programming, , , , , ,

Introduction

Le Dependency Inversion Principle (DIP) réside en deux règles:

  1. High level modules should not depend upon low level modules. Both should depend upon abstractions. ( Les modules de haut niveau ne doivent pas dépendre des modules de bas niveau. Les deux doivent dépendre d’abstractions.)
  2. Abstractions should not depend upon details. Details should depend upon abstractions ( Les abstractions ne doivent pas dépendre des détails. Les détails doivent dépendre des abstractions.)

SOLID Partie IV : Interface Segregation Principle

En français, Programming, , , , ,

Introduction

Comme toujours avec les principes SOLID, l’enjeu est la maintenabilité du code. On s’intéresse en particulier au couplage. Si ce n’est pas déjà fait, je vous invite à lire SOLID Partie I : Single Responsibility Principle car les idées défendues dans l’Interface Segregation Principle (ISP) sont proches de celles du SRP. En effet, alors que le SRP défendait l’idée qu’une classe ne devrait avoir qu’une seule responsabilité (“il ne devrait y avoir qu’une seule raison de changer une classe”), l’ISP va plus loin en appliquant ce principe aux interfaces. Continue reading SOLID Partie IV : Interface Segregation Principle →

SOLID Partie III : Liskov Substitution Principle

En français, Programming, , , , ,

Introduction

Let ϕ(x) be a property provable about objects x of type T. Then ϕ(y) should be true for objects y of type S where S is a subtype of T.

 Barbara Liskov, Jeannette Wing, “A behavioral notion of subtyping”,1994

Liskov et Wing définissent un sous-type (ou une sous-classe) par substituabilité : S est un sous-type de T si l’on peut toujours remplacer un objet de type T par un objet de type S.
Nous n’allons pas rentrer ici dans les aspects théoriques de cette définition, ni détailler les travaux de Barbara Liskov, mais retenons simplement ceci : une sous-classe n’est une sous-classe que si elle se comporte comme sa classe mère, c’est-à-dire que l’on peut remplacer une instance de la classe mère par une instance de la classe fille.

Le corollaire de ce principe est qu’une sous-classe ne doit pas rompre un “contrat” établi par la classe mère. C’est le Design By Contract de Bertrand Meyer Continue reading SOLID Partie III : Liskov Substitution Principle →

SOLID Partie II : Open/Closed Principle

En français, Programming, , , , , , , , , ,

Introduction

Dès lors qu’un logiciel est, avec le temps, amené à être modifié, que ce soit afin d’y ajouter des fonctionnalités ou de modifier certains comportements, des problèmes de régression se posent. Au fil des versions la qualité tend à diminuer et la maintenabilité aussi. Continue reading SOLID Partie II : Open/Closed Principle →

SOLID Partie I : Single Responsibility Principle

En français, Programming, , , , , , ,

Introduction

Robert C. Martin, le père de SOLID, introduit le Single Responsibility Principle (SRP) en ces termes:

“There should never be more than one reason for a class to change.”

“Il ne devrait jamais y avoir plus d’une raison de changer une classe.” Continue reading SOLID Partie I : Single Responsibility Principle →

SOLID – Introduction

En français, Programming, , , , ,

On peut constater que la plupart des développeurs qui utilisent quotidiennement la programmation orientée objet connaissent généralement non seulement ses grands principes (interfaces, classes, héritage, polymorphisme, etc.) mais aussi une ribambelle de design patterns qu’ils essaient de placer un peu partout, sans forcément en connaître les subtilités. Continue reading SOLID – Introduction →