nov. 20 2010

[ASP.NET] Design Patterns et Best Pratices - Partie 2 : Principes de conception et principes SOLID

Suite au précédent billet d'introduction nous allons voir les principes de conception constituent les fondements que les Design Patterns ont mis à profit. On peut dire qu'ils sont plus fondamentaux que les Patterns et constituent la base d'un développement de qualité. Lorsque vous suivez ces principes  éprouvés, votre code devient infiniment plus souple et plus adaptable aux changements, ainsi que plus facile à gérer. Je vais vous présenter brièvement quelques-uns des principes de conception les plus connus ainsi qu'une série de principes connue sous le nom de SOLID. Je reviendrais plus en détails sur chacun d'eux, dans les prochains billets, avec un cas pratique en ASP.NET.

Les principes de conception

Il existe un certain nombre de principes de conception qui, comme les Design Patterns, sont devenus des Best Pratices au fil des ans et ont aidé à former une base sur laquelle des applications maintenables peuvent être construites. Voici les plus connus :

  • Keep It Simple Stupid (KISS) : De nombreux développeurs éprouvent la nécessité de compliquer une solution. L'objectif du principe KISS est de maintenir un code simple, stupide, en évitant ainsi toute complexité inutile.
  • Don't Repeat Yourself (DRY) : Le principe DRY vise à éviter la répétition de tout ou partie d'une application en utilisant les concepts d'abstraction. Autrement dit, DRY rappelle qu'il ne faut pas avoir de duplication de code. En effet, les blocs de codes dupliqués devraient être déplacés dans une fonction ou dans une classe afin de pouvoir être réutilisables partout ailleurs. Ce principe permet donc une plus grande abstraction et diminue la complexité. La maintenabilité de l'application est aussi améliorée dans le sens ou les modifications du code n'auront plus à être reportées à différents endroits.
  • Tell, Don’t Ask : Ce principe est étroitement aligné avec l'encapsulation et l'attribution des responsabilités à leurs classes correctes. Ce principe stipule que vous devez dire à des objets les actions que vous souhaitez qu'ils effectuent plutôt que de poser des questions sur l'état de l'objet, puis de prendre une décision vous-même sur l'action que vous souhaitez effectuer. Cela permet d'aligner les responsabilités et éviter un couplage étroit entre les classes.
  • You Ain't Gonna Need It (YAGNI) : Le principe YAGNI se réfère à la nécessité d'inclure uniquement les fonctionnalités qui sont nécessaires à l'application maintenant. Il faut donc mettre de côté toute tentation d'ajouter d'autres fonctionnalités que vous pensez avoir peut-être besoin. Une méthodologie de conception qui adhère au principe YAGNI est le développement piloté par les tests (Test Driven Development ou TDD).
  • Separation of Concerns (SoC) : Le principe SoC est le processus de séparation de parties d'une application en des outils distincts (ayant un comportement et des données propres) et qui puisse être réutilisés par d'autres classes. Le principe de Separation Of Concerns dérive en fait du principe de Single Responsibility (une classe fait une chose et une seule).

Connaître les différents Patterns du GoF, c'est une bonne chose. Mais il est d'autant plus important de respecter ces principes de conception de base. C'est le cas également pour les principes SOLID.

Les principes SOLID

Les principes SOLID sont un recueil des Best Pratices pour la conception orientée objet. Tous les Designs Patterns du Gang of Four adhérent à ces principes dans une forme ou une autre. Le terme S.O.L.I.D. provient de la première lettre de chacun des cinq principes fondamentaux qui ont été recueillis dans le livre Agile Principles, Patterns, and Practices de Robert C. Martin (alias Uncle Bob), dont une version pour le C# est disponible. Voici les fameux principes que tout développeur objet se doit connaître :

  • Single Responsibility Principle (SRP) : Le principe SRP, comme vu plus haut, est étroitement aligné sur le principe SoC. Il indique que chaque objet ne doit avoir qu'une seule raison de changer et une seul responsabilité. En adhérant à ce principe, on évite le problème de la conception de classe monolithique (la classe couteau suisse à la MacGyver). Il ne va pas sans dire que ce principe améliore la lisibilité du code et la maintenance d'une application.
  • Open-Closed Principle (OCP)  : Le principe OCP stipule que les classes doivent être ouvertes aux extensions, mais fermées aux modifications, pour ainsi être en mesure d'ajouter de nouvelles fonctionnalités et d'étendre une classe sans modifier son comportement interne. Le principe vise à éviter de casser la classe existante et d'autres classes qui en dépendent, ce qui créerait un effet d'entraînement des bugs (effet cascade ou effet de bord dans le jargon).
  • Liskov Substitution Principle (LSP) : Le principe LSP exige que vous devriez être capable d'utiliser toute classe dérivée à la place d'une classe mère et d'avoir le même comportement sans modification. Ce principe est lié au principe précédent puisqu'il garantit qu'une classe dérivée n'affecte pas le comportement d'une classe parent. Pour résumer ce principe, on doit toujours être capable de substituer une classe dérivée à la classe parent sans aucun problème.
  • Interface Segregation Principle (ISP) : Le principe ISP consiste à éviter qu'un client ait besoin de mettre en œuvre une grande interface et une foule de méthodes qu'il n'utilise pas. En gros, cela vise à séparer les interfaces selon leur responsabilité, et implémenter uniquement celles nécessaire dans une classe, plutôt que d'avoir une seule interface couteau suisse.
  • Dependency Inversion Principle (DIP) : Le principe DIP consiste à isoler vos classes d'implémentations concrètes et de les faire dépendre uniquement de classes abstraites ou interfaces. DIP augmente la flexibilité dans un système en veillant à ce que vos classes ne soient pas étroitement couplées à une mise en œuvre ou une implémentation précise. Deux autre principes bien connus, l'injection de dépendance (Dependency Inversion Principle ou DI) et l'inversion de contrôle (Inversion of Control ou IoC) sont étroitement liés à ce principe. Je reviendrais dessus dans un autre billet.

Pour voir plus en détails ces principes, je vous recommande de lire l'article de Philippe Vialatte : Bonnes pratiques objet en .net : Introduction aux principes SOLID. Bien que ces cinq principes de l'oncle Bob se nomment SOLID, sachez qu'il ne s'est pas arrêté en si bon chemin. Il existe six autres pincipes qui concernent surtout les packages. Dans ce contexte, un package est un délivrable binaire (comme une dll / assembly, ou un fichier .jar en java). Voici, à titre indicatif leur nom ainsi qu'un lien vers le document original d'oncle Bob :

C'est tout pour aujourd'hui. Dans le prochain billet je vais revenir plus en détails sur les 23 Design Patterns du Gang of Four et leur classification. Dans le quatrième billet de la série, nous verrons cela plus concrètement avec un exemple de refactoring en ASP.NET afin d'illustrer les principes expliqués jusqu'à présent.

Tags: , , , ,

Commentaires

1.
pingback topsy.com says:

Pingback from topsy.com

Twitter Trackbacks for
        
        [ASP.NET] Design Patterns et Best Pratices - Partie 2 : Principes de conception et principes SOLID
        [nicolasesprit.com]
        on Topsy.com

2.
Maxence Maxence Luxembourg says:

Très bonne série d'articles. Ca fait du bien de revoir les bases parfois.

3.
Thibault Laurens Thibault Laurens France says:

Excellent !

Je suis en plein dedans et ça m'aide beaucoup. Merci.

Pourrait on avoir un pdf regroupant les 4 articles plus tard ?

4.
Thibault Laurens Thibault Laurens France says:

Excellent !

Je suis en plain dedans en ce moment et ça m'aide beaucoup. Merci.

Pourrais avoir un pdf regroupant les 4 articles plus tard ?

5.
Nicolas Nicolas France says:

Salut,

Content de voir que la série soit utile.

Je compte effectivement regrouper le tout en un seul article, que je publierais surement sur Developpez.com, donc disponible au format PDF. Après, je ne saurais dire s'il y aura quatre billets ou plus. Pour l'instant je suis bien parti pour en faire plus Smile

6.
trackback Nicolas Esprit says:

[ASP.NET] Design Patterns et Best Pratices - Partie 3 : Les Patterns du Gang of Four

[ASP.NET] Design Patterns et Best Pratices - Partie 3 : Les Patterns du Gang of Four

7.
trackback ASP.NET Français Blogs says:

[ASP.NET MVC] Nouveautés MVC 3 Part 9 - Sessionless Controllers, Viewstart, IMetadataAware et ViewBag

ASP.NET MVC 3 apporte d'autres petites améliorations qu'il est important de noter : les

Les commentaires sont clos