Voir la source de Les principes de la conception orientée objet

[[Category: Portail Equipe de développement]]
[[Category: Robert Martin]]
Auteur : Robert C. Martin<br/>
Source : [http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod The Principles of OOD]<br/>
----
Traducteur : Fabrice Aimetti<br/>
Date : 13/08/2009<br/>
----
Traduction :<br/>
<br/>
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.<br/>
<br/>
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.<br/>
<br/>
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.<br/>
<br/>
En Mars 1995, dans comp.object, j’ai écrit un [https://groups.google.com/forum/?hl=en#!topic/comp.object/WICPDcXAMG8 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 [http://www.objectmentor.com/PPP/ PPP], et dans de nombreux articles sur le site [http://www.objectmentor.com/ objectmentor], dont le bien connu [http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf article de synthèse].<br/>
<br/>
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.<br/>
<br/>
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" :<br/>
<br/>
[[Fichier:Robert-martin-coo1.png]]<br/>
<br/>
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++.<br/>
<br/>
Les trois premiers principes sont sur la "cohésion" des packages et nous disent ce qu’il faut mettre dans les packages :<br/>
<br/>
[[Fichier:Robert-martin-coo2.png]]<br/>
<br/>
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 :<br/>
<br/>
[[Fichier:Robert-martin-coo3.png]]