Les principes de la conception orientée objet

De Wiki Agile du @GroupeCESI
Aller à : navigation, rechercher

Auteur : Robert C. Martin
Source : The Principles of OOD
Date : Mai 2005


Traducteur : Fabrice Aimetti
Date : 13/08/2009


Traduction :

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 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, et dans de nombreux articles sur le site objectmentor, dont le bien connu article de synthèse.

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" :

Robert-martin-coo1.png

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 :

Robert-martin-coo2.png

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 :

Robert-martin-coo3.png