Fathi Bellahcene

Présentation des principes SOLID

Ces derniers temps, j’ai la chance de travailler au sein d’une équipe qui s’est décidé de faire la guerre au code tout pourri…et c’est la que les principes SOLID on fait leur apparition.

Du coup, j’ai le bonheur d’écouter et parfois de participer à des débats enflammés à leur sujet et bien sûr on a le droit à un bonne dose de mauvaise foi; de coup sous la ceinture; de chevilles qui enfles…bref de bonnes tranches de rigolades surtout lorsque l’heure fatidique du “verre” approche (si vous ne voyez pas de quoi je parle, demandez à un de vos amis alcoolique).

J’ai donc décidé de (re) présenter ces principes sur ce blog parce que c’est un sujet que je trouve passionnant et qui m’interresse beaucoup. Mon objectif sera d’utiliser des exemples les plus compréhensibles possible mais sans être complètement déconnecté de la réalité. Je vais également m’appuier sur l’article que j’ai publié à ce sujet sur le magazine Programmez avec Jason De Oliveira.

Je vais donc suivre le plan suivant:

• Présentation générale des principes (ce post)
• présentation des principes:
  • Single Responsibility Principle.
  • Open-Closed Principle.
  • Liskov Substitution Principle.
  • Interface Segregation Principle.
  • Dependency Inversion Principle.
• Conclusion: concrètement on fait comment?

Pourquoi SOLID?

Lorsque je demande ce qu’il faut pour sortir un logiciel de qualité , j’ai souvent les réponses suivantes:

• faire des tests unitaires
• contrôler la couverture de code
• contrôler les dépendances de nos modules
• contrôler le niveau de commentaires dans le code.
• avoir un bon outil de gestion de sources
• Avoir un bon bug tracker
• utiliser une bonne méthodologie (agile) de conduite de projet
• controler le code (fxcop, styleCop,gendarme…)
• avoir une build pour tout automatiser et tout remonter de manière automatique

Tout ca c’est bien, mais il manque à mon sens une chose importante: la qualité du design!

Aujourd’hui, vous pouvez avoir un code avec une excellente couverture de code, sans erreurs FxCop, bien commenté et s’assurer que vous avez une complexité cyclomatique inférieur à 13 tout plein de metrics qui nous permettent de porter un jugement sur certains aspect du code … et avoir un design calamiteux. pourquoi? parce tout ca manque de cohésion: on a pas de but à atteindre ni de direction à suivre.

Ce que j’éssaie de dire ici, c’est qu’aujourd’hui vous pouvez démarrer un projet avec un super outillage sur deux parties essentiel :

• le “bas niveau” : check du code avec les outils précédement cités
• le “haut niveau” : la conduite de projet avec les méthodologies agiles

Par contre pour ce qui est du niveau intermédiaire la qualité du design (pas du code) : RIEN!

…enfin presque rien, on a tout de même les principes SOLID.

SOLID c’est quoi ?

C’est un ensemble de principe regroupé par Robert C. Martin qui concerne la programmation orienté objet. Le but de ces principes est d’améliorer le design de vos applications et ainsi les rendre plus facilement maintenable et lisible et faciliter les éventuelles évolutions. Ils sont au nombre de 5

1. Single Responsibility Principle (Principe de la responsabilité unique)
2. Open-Closed Principle (Principe Ouvert-Fermé)
3. Liskov Substitution Principle (Principe de substitution de Liskov)
4. Interface Segregation Principle (Principe de ségrégation des interfaces)
5. Dependency Inversion Principle (Principe d'inversion de dépendance)

Ces principes ne s’intéresse pas au code dans le sens ou il ne vont pas vous imposer de nommer vos variables de tels ou tels manières, de bien commenter votre code, ou encore de rendre toutes vos classes d’exception serialisables. Elles vont plustout vous indiquer quelles sont les erreurs de design qui sont dans votre code et comment les supprimer.

Pour finir (la chose la plus intéressante de ce post), je me permet de copier ce qu’en dit Robert C. Martin sur le site de sa société:

The SOLID principles are not rules. They are not laws. They are not perfect truths. The are statements on the order of “An apple a day keeps the doctor away.” This is a good principle, it is good advice, but it’s not a pure truth, nor is it a rule.

The principles are mental cubby-holes. They give a name to a concept so that you can talk and reason about that concept. They provide a place to hang thefeelings we have about good and bad code. They attempt to categorize those feelings into concrete advice. In that sense, the principles are a kind of anodyne. Given some code or design that you feel bad about, you may be able to find a principle that explains that bad feeling and advises you about how to feel better.

These principles are heuristics. They are common-sense solutions to common problems. They are common-sense disciplines that can help you stay out of trouble. But like any heuristic, they are empirical in nature. They have been observed to work in many cases; but there is no proof that they always work, nor any proof that they should always be followed.

Je vous donne donc rendez-vous sur le prochain post pour parler de SRP!

Vous trouverez les sources des exemples ici:http://solidincsharp.codeplex.com/