Developpez.com

Plus de 2 000 forums
et jusqu'à 5 000 nouveaux messages par jour

La réutilisation dans la POO et ses limites actuelles :
Est-il possible d'y remédier ? Que faut-il faire ?

Le , par Arsene Newman, Expert éminent sénior
Au début des années 1990, l’un des principaux concepts faisant l’éloge de la programmation orientée objet était la réutilisation. Aujourd’hui, Scott Westfall, programmeur et chef de projet, revient sur ce concept et sa situation actuelle dans un billet de blog.

« Il n’est pas rare de découvrir que plusieurs personnes au sein de votre équipe ont codé essentiellement la même fonctionnalité. Clairement, cela illustre un manque de réutilisation de code efficace ». C’est en ces termes que s’est prononcé Westfall. Mais qu’en est-il réellement de la réutilisation de code ?
Aux premiers abords, ce concept désigne la réutilisation de code, de classes et des modèles de conception existants au lieu d’en créer des nouveaux. Mais, pour Westfall c’est plus que cela : « Il s’agit plus de l’efficacité du code que de l’efficacité de la programmation ».

En outre, pour ce professionnel, une compréhension de cette situation passe inévitablement par répondre à certaines questions :

  • Pourquoi les développeurs ne réutilisent pas le code existant ? Le blogueur évoque certaines raisons comme :
    • déterminer les parties réutilisables d’un code est difficile ;
    • le manque de documentation : si les éléments réutilisables ne sont pas documentés, leur utilisation devient plus complexe ;
    • les développeurs ne prennent pas le temps de chercher du code réutilisable ;
    • un élément réutilisable peut altérer le modèle de conception, ce qui implique un rapport avantages/coûts défavorable.
    • l’écriture de code de manière non réutilisable. Ce dernier point nous renvoie directement à la seconde question.
  • Pourquoi les développeurs ne codent pas de manière à réutiliser le code ?
    • Ecrire un code réutilisable demande plus d’efforts.
    • Manque de temps : les développeurs manquent de temps pour écrire un code réutilisable, même si notre blogueur a une vision différente : « En réalité, beaucoup de développeurs arrivent à trouver du temps pour coder quelque chose pour leur propre utilisation, mais n’arrivent pas à en trouver pour ce cas de figure».
    • Bénéfices : à l’heure actuelle, le cycle de vie d’un code est généralement assez court, ainsi, les développeurs ne voient pas les bénéfices d’un code réutilisable.


Ajouter à cela, les propos de Westfall évoquent un autre facteur justifiant la situation actuelle : « même quand il y a une réutilisation du code décente, la réutilisation des modèles de conception est souvent négligée malgré le meilleur retour sur investissement qu’elle offre ». En effet, la réutilisation des modèles de conception offre beaucoup d’avantages, mais, en contrepartie, une bonne documentation et des templates de code sont nécessaires, ce qui la marginalise.

Faut-il abandonner la réutilisation à son sort actuel ? Non, malgré ces problèmes, la réutilisation est importante. Quand les choses sont faites correctement, cela n’accélère pas uniquement le développement, mais permet aussi de créer des fonctionnalités qui fonctionnent avec constance au sein d’une application ».

Alors, quelle est la solution pour y remédier ? Pour Westfall, une approche centrée sur l’architecture et sur sa maintenance en impliquant davantage les développeurs permettrait à ces derniers de les responsabiliser, de mieux reconnaître les éléments réutilisables de leur code et à penser plus à la réutilisation.

Enfin, Westfall évoque ce qui suit : « si une compagnie est suffisamment grande, vous pouvez dédiés du personnel à la collecte et à la gestion des éléments réutilisables. Je vois ces personnes-là comme étant plus des bibliothécaires que des architectes »

Source : Billet de blog de Scott Westfall
Et vous ?

Que pensez-vous de la réutilisation en POO ?

Faites-vous souvent appel à la réutilisation en POO ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de Luckyluke34 Luckyluke34 - Membre chevronné http://www.developpez.com
le 31/03/2014 à 12:08
La réutilisation, c'est bien, mais ce n'est pas aussi simple que repérer des blocs de code en doublon et les extraire dans de nouvelles méthodes/classes, ou se dire que ce truc là-bas ressemble vaguement à ce dont on a besoin et l'utiliser.

Réutiliser nécessite un gros travail d'abstraction, de découpage et de nommage. Il faut tirer l'essence d'un bloc de code pour mettre un nom précis et adéquat dessus et lui donner un contrat clair, éventuellement distinguer ses différentes responsabilités pour les extraire dans des éléments séparés... C'est une des choses les plus compliquées en programmation.

Même une fois qu'on a fait ça, réutiliser un composant ne sert à rien si on sait que celui-ci risque de changer pour des raisons totalement indépendantes de notre besoin actuel et de devenir incompatible, ou nous force à rentrer dans un moule qui va apporter de la complexité inutile ou des dépendances non désirées vers d'autres composants.

Honnêtement, je vois plus souvent du code réutilisé mal à propos, des abstractions mal nommées ou faisant 10 choses + le café, des frameworks dont on n'utilise que 2% des fonctionnalités qu'on se traine comme des boulets, que du code pas assez réutilisé.
Avatar de DonQuiche DonQuiche - Expert confirmé http://www.developpez.com
le 31/03/2014 à 13:47
Je suis surpris que personne n'ait mentionné le principal obstacle à la ré-utilisabilité : le système de types et les limites du polymorphisme. Entre les types paramétriques trop peu spécifiques, les langages substituant à l'héritage multiple des interfaces sans code (donc redéfinition obligatoire), les conflits de nommage entre les besoins (l'identifiant de l'un est l'index de l'autre) pas forcément simplifiable grâce à un accesseur (parce qu'il faut un accès par référence), etc, on peut dire que les typages statiques font beaucoup pour empêcher la réutilisabilité. Bien souvent ça se termine avec une usines à gaz de douze classes à la fonction obscure pour réutiliser douze lignes.

Et si on ajoute à ça les problèmes de performances, le couplage accru, les subtiles différences de comportements, etc, tout ce qui semble a priori intéressant à généraliser ne l'est pas.

En attendant beaucoup de langages doivent être enrichis.
Avatar de black_soul black_soul - Nouveau Candidat au Club http://www.developpez.com
le 31/03/2014 à 16:31
Depuis que j'ai codé cette classe, je gagne un temps juste énorme puisque la plupart des éléments dans la base de données d'un site ont besoin des mêmes traitements : Récupérer, trier, publier ...

Code php : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
  
abstract class ContentNode 
{ 
	protected $pdo; 
	protected $nodeTableName; 
	protected $nodeIdName; 
  
	public function ContentNode($pdo,$nodeTableName="",$nodeIdName="") 
	{ 
		$this->pdo = $pdo; 
		$this->nodeTableName = $nodeTableName; 
		$this->nodeIdName = $nodeIdName; 
	} 
  
	public function getItemById($id) 
	{ 
		$sql="SELECT * FROM ".$this->nodeTableName." WHERE ".$this->nodeIdName."=?"; 
		$query=$this->pdo->prepare($sql); 
		$query->execute(array($id)); 
  
		return $query->fetch(); 
	} 
  
	public function switchItemActivation($item) 
	{ 
		$active = 0; 
  
		if($item['actif'] == 0) $active = 1; 
  
		$sql="UPDATE ".$this->nodeTableName." SET actif=? WHERE ".$this->nodeIdName."=?"; 
		$query=$this->pdo->prepare($sql); 
		$query->execute(array($active,$item[$this->nodeIdName])); 
	} 
//....

Tout le problème étant qu'il répéter les mêmes actions un sacré paquet de fois avant de savoir ce qui marche, ce qui ne marche pas et standardiser son propre code pour qu'il puisse coller au plus de cas possible.
Avatar de Washmid Washmid - Membre actif http://www.developpez.com
le 31/03/2014 à 17:06
@Luckyluke34 : Pour le coup de réutiliser les codes en doublon, il y a checkstyle qui fonctionne redoutablement bien ! Code dupliqué : Warning.

Et pour pouvoir réutiliser, je ne suis pas d'accord avec toi. Il ne faut pas tirer l'essence d'un bloc. Il faut que la personne qui a écrit ce bloc ait écrit la doc (javadoc, csdoc, ce-que-tu-veux-doc).

Le problème dans la réutilisation, c'est qu'il faut une doc, donc il faut que la personne qui écrit le code sous cette doc ait les idées claires sur le contrat de la classe / méthode qu'il est en train d'écrire.
Avatar de tomlev tomlev - Rédacteur/Modérateur http://www.developpez.com
le 31/03/2014 à 17:18
Que pensez-vous de la réutilisation en POO ?

C'est un bon principe, mais il faut rester pragmatique ; si rendre le code réutilisable le rend trop complexe, ça ne vaut pas le coup.

Faites-vous souvent appel à la réutilisation en POO ?

Autant que possible, oui.

La plupart du temps, un bout de code non trivial est écrit pour un besoin précis, pas dans l'idée d'être réutilisé. C'est seulement après coup qu'on se rend compte qu'on a besoin de le réutiliser, généralement avec des petites variantes. Dans ces cas là, un petit coup de refactoring permet généralement d'éviter la duplication de code, en ajoutant des paramètres à une méthode ou des dépendances à une classe.

(ce débat tombe à pic, je suis justement en train de me prendre la tête sur un refactoring pour éviter de dupliquer un bout de logique métier... et je commence à me demander si ça en vaut la peine )
Avatar de barmic barmic - Membre habitué http://www.developpez.com
le 31/03/2014 à 18:01
AMHA le problème principal est un problème de modélisation. Il n'est pas simple de savoir comment découper son travail pour le rendre réutilisable ou du moins il est compliqué de savoir quand est-ce que ça va être utile. Le fait de s'obliger de tester unitairement son code aide beaucoup à créer des parties réutilisables (puisqu'elles sont de fait utiliser en production et dans les tests).

Il y a des principes qui restent à mon avis pas assez connus :
  • créer des packages par fonctionnalités et pas par couche
  • éviter les effets de bord comme la peste
  • penser son code comme une API
  • découper son code et utiliser de l'injection de dépendance
Avatar de Zefling Zefling - Membre émérite http://www.developpez.com
le 31/03/2014 à 18:02
Rendre réutilisable du code peut parfois demande tellement temps que s'il n'est pas réutiliser plus de 3-4 fois, ça peut aller plus vite d'adapter, puis si besoin réel de refaire une refacto. Si on doit tout anticiper on ne s'en sort plus, le temps n'est pas infini...
Avatar de barmic barmic - Membre habitué http://www.developpez.com
le 31/03/2014 à 18:14
Citation Envoyé par Zefling  Voir le message
Rendre réutilisable du code peut parfois demande tellement temps que s'il n'est pas réutiliser plus de 3-4 fois, ça peut aller plus vite d'adapter, puis si besoin réel de refaire une refacto. Si on doit tout anticiper on ne s'en sort plus, le temps n'est pas infini...

Il y a des choses facilement réutilisables qui ne le sont que rarement (de mon expérience).
Si déjà c'était fait pour ce genre de choses ça irait déjà mieux.

J'ai même vu des duplications de code simplement par mauvaise modélisation objet (mal connaissance du polymorphisme, de son intérêt et de comment l'obtenir). Je travail avec des langages qui n'ont pas de traits et je me demande si ça ne serait pas plus simple pour certains de faire de la réutilisation à base de traits plutôt qu'avec de l'héritage.
Avatar de pcaboche pcaboche - Rédacteur http://www.developpez.com
le 31/03/2014 à 18:25
Citation Envoyé par Arsene Newman  Voir le message
Que pensez-vous de la réutilisation en POO ?

La question à se poser, c'est plutôt : Quelles sont les techniques de réutilisation en POO ?

  • définir un template / Generic pour appliquer un même algorithme / une même structure de données à des types différents ?
  • utiliser l'héritage, la surcharge et le polymorphisme pour créer une nouvelle classe avec un comportement différent ? (d'où la multiplication à outrance du nombre de classes)
  • utiliser un pattern Strategy ou Template Method ?


Désolé, mais c'est plutôt limité...

À l'inverse, la programmation fonctionnelle a une certaine tendance à promouvoir la réutilisabilité :

  • fonction d'ordre supérieure : on définit une fonction f qui prend une fonction g en paramètre. f définit l'algorithme général et g un comportement spécifique de cet algorithme. L'écriture de code consiste souvent à assembler des fonctions d'ordre supérieur avec d'autres fonctions
  • "partial application" : on définit une fonction f avec un comportement générique (dans le sens où elle peut faire beaucoup de choses différents suivant les paramètre), puis on la "spécialise" en fixant un ou plusieurs de ses paramètres, ce qui nous donne une nouvelle fonction g
  • inférence de type : j'ai une fonction de type ('a -> 'a -> 'a), je lui passe un entier et ça devient une fonction de type (int -> int -> int); comme les templates / Generics, mais la syntaxe en moins...


Au bout d'un moment, écrire des fonctions aussi génériques que possible, ça devient presque une seconde nature ! (et on essaye de transposer ça en POO).

D'ailleurs, en POO on y vient gentiment avec les délégués, les lambdas... mais on sent bien que c'est pas aussi naturel qu'en programmation fonctionnelle, ne serait-ce qu'au niveau de la syntaxe :

Code : Sélectionner tout
1
2
3
4
public static T DoSomeStuff<A, B, T>(System.Funct<A, B, T> f, A a, B b) { ... 
 
// Au lieu de: 
// let doSomeStuff f a b = ...


Citation Envoyé par Arsene Newman  Voir le message
Au début des années 1990, l’un des principaux concepts faisant l’éloge de la programmation orientée objet était la réutilisation.

En fait, le principal argument de la POO, c'était surtout l'encapsulation.
Pour caricaturer, le fait de pouvoir représenter certains concepts en les rangeant dans des petites boites (les classes) afin de produire de joli diagrammes UML, ça faisait plaisir aux décideurs qui ne mettent jamais le nez dans le code.

Autre facteur non négligeable : ces concepts de classes semblent assez naturels et simples à appréhender (du moins au début...), donc que on s'est dit que ce serait plus facile de former de la main d'oeuvre dans ce domaine.

Du coup, l'industrie s'est rendu compte que ça arrangeait tout le monde :
- les managers / concepteurs / architectes s'échangent des jolis diagrammes UML (qu'on compile dans des documents appelés "specs")
- on dispose de millions d'Indiens pour transformer ces specs en code

C'est comme ça que la POO est devenue le paradigme de facto dans l'industrie (parce que ça permet de communiquer des idées, souvent les mêmes, à du personnel considéré comme parfaitement interchangeable; pas parce que ça permet la réutilisation du code).

Parce que les méthodes de réutilisation de code en POO, c'est pas l'idéal.
Avatar de MABROUKI MABROUKI - Membre émérite http://www.developpez.com
le 31/03/2014 à 18:34
C'est un vieux debat depuis la naissance de la POO...

Djiskra disait que cette idee ne pouvait naitre qu'en Californie....

Entendaient par là ,qu'elle vise comme le "Fordisme" à standardiser la production de code...pour la production en serie....

L'esprit americain ayant invente le "standard industriel",le "module"....
Tout le reste n'est que discussion de details pour developpeurs....
Offres d'emploi IT
Conseiller commercial hosting (H/F)
IKOULA - Ile de France - Boulogne-Billancourt (92100)
Formateur logiciel aeronautique h/f
CTS - Midi Pyrénées - Toulouse (31000)
Lead Developper / Chef de projet PHP H/F
fusacq - Ile de France - Paris (75009)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil