Les Principes de la Conception Orientée Objet

((/dotclear/public/programmation.gif|Programmation|L|Programmation, aoû 2009))J’ai traduit un article fondateur écrit par Robert C. Martin (++[Uncle Bob|http://en.wikipedia.org/wiki/Robert_Cecil_Martin]++) le 11 mai 2005 : « ++[The Principles of OOD|http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod|en]++ ».%%% %%% > Qu’est-ce-que la conception orientée objet ? De quoi ça parle ? Quels en sont les bénéfices ? Quel est son coût ? Cela peut sembler absurde de poser ces questions à une époque où presque tous les développeurs de logiciels utilisent un langage orienté objet. Mais la question est importante car, il me semble que la plupart d’entre nous utilisent ces langages sans savoir pourquoi, et sans savoir comment en tirer le plus grand bénéfice.%%% > %%% > De toutes les révolutions qui ont eu lieu dans notre métier, deux ont remporté un tel succès qu’elles ont influencé notre façon de penser, à un tel point que nous les prenons pour acquis. La Programmation Structurée et la Programmation Orientée Objet. Tous nos langages modernes sont fortement influencés par ces deux disciplines. En effet, il est devenu difficile d’écrire un programme qui ne reflète pas à la fois une programmation structurée et une programmation orientée objet. Nos principaux langages n’ont pas de __goto__, et semblent donc obéir à la plus célèbre condamnation de la programmation structurée. La plupart de nos principaux langages sont fondés sur la notion de classe et ne prennent pas en charge les fonctions ou variables qui ne sont pas dans une classe, par conséquent, ils semblent respecter les principes les plus évidents de la programmation orientée objet.%%% > %%% > Les programmes écrits dans ces langages peuvent sembler à première vue structurés et orientés objet, mais en y regardant de plus près on peut être déçu. La plupart des programmeurs d’aujourd’hui ne sont pas conscients des principes fondateurs dont dérivent leurs langages. Je discuterai dans un autre billet des principes de la programmation structurée. Dans ce billet je souhaite parler des principes de la programmation orientée objet.%%% > %%% > En Mars 1995, dans comp.object, j’ai écrit un ++[article|http://tinyurl.com/84emx|en]++ qui a été le point de départ d’une série de principes concernant la Conception Orientée Objet sur laquelle j’ai écrit plusieurs fois depuis. Vous les verrez documentés dans mon livre ++[PPP|http://www.objectmentor.com/PPP/|en]++, et dans de nombreux articles sur le site ++[objectmentor|http://www.objectmentor.com/]++, dont le bien connu ++[article de synthèse|http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf|en]++.%%% > %%% > Ces principes traitent de la gestion des dépendances en Conception Orientée Objet, par opposition à la conceptualisation et la modélisation. Cela ne veut pas dire que l’Orienté Objet est un mauvais outil de conceptualisation ou de modélisation. De nombreuses personnes utilisent très certainement avec succès ces aspects de l’Orienté Objet. Mais ces principes insistent très fortement sur la gestion des dépendances.%%% > %%% > La Gestion des Dépendances est une question à laquelle la plupart d’entre nous ont dû faire face. Chaque fois que nous lisons sur nos écrans un code pourri et fouillis, nous constatons les résultats d’une mauvaise gestion des dépendances. Une gestion des dépendances médiocre conduit à un code qui est difficile à maintenir, fragile, et non réutilisable. J’aborde ces problématiques dans mon livre PPP, toutes liées à la gestion des dépendances. Lorsque les dépendances sont bien gérées, le code reste flexible, robuste et réutilisable. La gestion des dépendances, par conséquent ses principes, est à la base des qualités intrinsèques souhaitées par les développeurs pour leurs logiciels.%%% > %%% > Les cinq premiers principes sont des principes de  »conception d’une classe » :%%% > %%% ///html

SRPLe Principe de Responsabilité Unique (The Single Responsibility Principle)Une classe ne doit avoir qu’une et une seule raison de changer.
OCPLe Principe Ouvert/Fermé (The Open Closed Principle)Vous devez pouvoir étendre le comportement d’une classe sans la modifier.
LSPLe Principe de Substitution de Liskov (The Liskov Substitution Principle)Les classes dérivées doivent pouvoir être remplacées par leurs classes de base.
DIPLe Principe d’Inversion des Dépendances (The Dependency Inversion Principle)Dépendez des abstractions, pas des compositions.
ISPLe Principe de Séparation des Interfaces (The Interface Segregation Principle)Écrivez des interfaces à granularité fine et qui sont spécifiques au client.
/// > %%% > Les six prochains principes sont sur les packages. Dans ce contexte, un package est un livrable binaire comme par ex. un fichier .jar, ou une dll par opposition à un namespace comme un package java ou un namespace C++.%%% > %%% > Les trois premiers principes sont sur la  »cohésion » des packages et nous disent ce qu’il faut mettre dans les packages :%%% ///html
REPThe Release Reuse Equivalency PrincipleLa granularité de réutilisation est la granularité de livraison.
CCPThe Common Closure PrincipleLes classes qui changent ensemble sont packagées ensemble.
CRPThe Common Reuse PrincipleLes classes qui sont utilisées ensemble sont packagées ensemble.
/// > Les trois derniers principes sont sur les couplages entre les packages, et parlent de métriques permettant d’évaluer la structure des packages d’un système :%%% ///html
ADPLe Principe d’Acyclicité des Dépendances (The Acyclic Dependencies Principle)Le graphe des dépendances des packages ne doit pas avoir de cycle.
SDPLe Principe des Dépendances Stables (The Stable Dependencies Principle)Dépendez de packages qui soient stables.
SAPLe Principe des Abstractions Stables (The Stable Abstractions Principle)L’abstraction encourage la stabilité.
///

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *