Discussion :

[Arsene Newman]

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

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 ?

[Luckyluke34]

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é.

[DonQuiche]

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.

[black_soul]

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 - Visualiser dans une fenêtre à part

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.

[Washmid]

@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.

[tomlev]

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 )

[barmic]

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

[Zefling]

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...

[barmic]

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.

[pcaboche]

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 - Visualiser dans une fenêtre à part

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 = ...

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.

[MABROUKI]

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....

[DonQuiche]

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

Dommage que la densité de trolls par ligne soit aussi élevée dans ton message car le fond était plutôt intéressant, la programmation fonctionnelle ayant en effet un très net avantage dans la réutilisabilité des algorithmes élémentaires. Mais reléguer le polymorphisme a un simple prétexte pour faire de jolis diagrammes, c'est quand même mépriser son intérêt dans les systèmes réels : la programmation fonctionnelle montre ses limites quand il te faut passer dix arguments ou recourir à des mécanismes tordus pour résoudre un problème où le polymorphisme est la bonne réponse.

Les deux paradigmes sont nécessaires et doivent cohabiter dans un même langage. C'est de plus en plus souvent le cas.

[la.lune]

Je crois que les bonnes conceptions basées fortement sur les design pattern aident aussi grandement à réutiliser son code. Une équipe qui bosse toujours avec les patterns reconnait directement le cas et se souvient du code déjà utilisé. Je ne parle pas juste en matière de conception pour les architectes, concepteurs .., mais ceux là pourront aussi facilement orienté le développeur à ne pas reprendre du code déjà existant, mais du code existant lors de l’implémentation déjà faite d'un pattern donné est facilement réutilisable.

Le problème c'est qu'en matière de conception beaucoup de gens tu va trouver qu'ils vont développés avec des langages objets et se font par exemple à des spécifications techniques du code écris manuellement en non pas en pure POO avec des digrammes UML, n'en parlons pas du code des squelettes déjà généré et une documentation du code avant même le codage des méthodes elles même.

Et quand ils font des diagrammes de class ils s'intéressent beaucoup plus à la conception de la partie model(entités) et non pas l’application en sa totalité qu'elle respecte un model vraiment à la POO bien basé sur des patterns.

J'étais aussi étonné d'une personne avoir un jour commenté dans de forum qu'en cas de génération de code, le code généré là en général ne sert à rien après il sera jeté, et ben je dis que soit le générateur ne génère pas quelque chose qui enchante le compilateur à 100%, soit vous ne savez pas vraiment comment s'en servir. C'est plutôt un gain de temps en programmation.

A titre de rappel qu'il y a des gens qui font des applications qu'avec des conceptions UML, et l'application est généré à 100% sans avoir à toucher quoi que ce soi dans le code, et il n y a même pas besoin de faire de test comme les testes unitaires, et autres fin de s'assurer si ça marche ou pas, non: tester c'est utiliser. Il y a bien sûr qu'il a un boulot aussi formels dedans.

Donc je reviens à dire que le fait que l'application ne soit pas sérieusement bien conçu contribue à une limite sur la réutilisation du code et la réutilisation est un travail qui se rend facile avec la collaboration de tous les membres de l'équipe.

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)

+1.
Certes c'est une grande limite dans les interfaces. Depuis les années 90 on nous définit qu'une interface n'a que des signatures de méthodes et possible de d'en hériter de plusieurs mais l’implémentation du corps de chaque méthode est obligatoire une fois dans la classe.

Par contre on voit maintenant Java dans sa dernière version 8 vient d’évoluer dans ce sens introduisant la notion d’implémentation par défaut d'une méthode d'interface, ce qui contribue grandement à la factorisation des méthodes et à la réutilisation du code sans souci.

Ainsi j’aurais aimé que cette notion d’implémentation par défaut des méthodes d'une interface se standardise comme la notion même d'interface.

Dans le moment qu'il faut signaler seulement que tu hérite de telle interface tu n'a pas besoin de définir le core et tu encore as devant toi l'héritage multiple et des techniques de gestion de conflit de nom. Donc il faut que cette notion soit répandu dans les autres langages comme la notion même d'interface, ça va bien contribuer grandement à la réutilisation du code.

Même si en réalité cette notion fut introduite pour les besoin d’extension sans toucher aux implémentations existantes, mais un grand avantage se pressente sur les nouvelle applications et les application futures et surtout aux concepteur d'API.

Là je profite l'occasion pour partager mon avis aux concepteurs qui ciblent Java 8, de même que les développeurs, en guise de rappel (je n'ai pas de leçon à donné à qui que se soit) qu'il y a actuellement une piste d'améliorer aussi la manière de conception et de développement, quand on a une méthode qui définit un comportement sur un objet indépendamment de son état il faut la coder dans une interface dans une méthode par défaut et en hériter. Du coup, une réutilisation totale prochainement sans modification.

Avec la possibilité aussi de manipuler des méthodes purement virtuelles dans cette implémentation par défaut et la possibilité aussi dans un cas particulier d'apporter quelques modification en cas de besoin dans une implémentation spécifique de la méthode dans la classe, et du polymorphisme à la portée . Comme j'ai dis dans la possibilité d'en hériter de plusieurs sans souci.

[moldavi]

Bonjour.

Enfin, Westfall évoque ce qui suit : « si une compagnie est suffisamment grande, ... »

Je crois que tout est dit ici. Le problème, ce ne sont pas les développeurs, ce sont les moyens, et encore.

En même temps je ne crois pas aux bibliothèques qui font le café. Chaque cas est particulier, et si une bibliothèque était capable de gérer tous les cas de figure avec les performances et la portabilité maximale, cela se saurait. Et on ne discuterait pas de cela ici.

Mais bon, responsabiliser le développeur qui travaille déjà 10 heures par jour, faut en vouloir. Le management n'a pas de limite visiblement.

[CodeurPlusPlus]

Je ne trouve pas qu'il est plus facile d'écrire du code réutilisable dans le paradigme impératif objet que dans le paradigme impératif procédural.

De toute façon, l'objet, on en reviendra bien un jour... c'était fait pour simplifier les choses et il se produit souvent tout le contraire. J'estime qu'il n'y a pas dix pourcents des problèmes qui sont plus faciles à résoudre en objet qu'en procédural ; aussi si plus de dix pourcents du code d'une application est "objet", c'est suspect.

Je trouve qu'on essaye souvent d'écrire du code réutilisable, qu'on se fait beaucoup ch... pour ça, et qu'en général on constate quelques années plus tard que cela n'a servi à rien. Soit le code n'est pas si réutilisable que prévu, soit on n'a pas besoin de le réutiliser.

Ecrire du code réellement réutilisable est une des taches les plus difficiles auxquelles un programmeur peut être confronté. Après de longues années d'expérience on commence à atteindre cet objectif relativement souvent (la définition de "souvent" dépendant sans doute de chacun). Mais c'est assurément quelque chose qu'aucune formation ne peut enseigner.

[Lupus Michaelis]

L'avantage, c'est vu que tu as centralisé l'accès à tes données, tu peux directement corriger une injection SQL potentielle :

Code php :

Sélectionner tout - Visualiser dans une fenêtre à part

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
35
36
37
38
39
40
41
42
43
abstract class ContentNode
{
	protected $pdo;
	protected $nodeTableName;
	protected $nodeIdName;
 
	private function EscapeAttributeName($attr_name)
	{
		return /* XXX To Implement */;
	}
 
	private function EscapeTableName($table_name)
	{
		return /* XXX To Implement  */;
	}
 
	public function ContentNode($pdo,$nodeTableName="",$nodeIdName="")
	{
		$this->pdo = $pdo;
		$this->nodeTableName = $nodeTableName;
		$this->nodeIdName = $nodeIdName;
	}
 
	public function getItemById($id)
	{
		$sql="SELECT * FROM ". $this->EscapeTableName($this->nodeTableName) ." WHERE ".$this->EscapeAttributeName($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->EscapeTableName($this->nodeTableName)." SET actif=? WHERE ".$this->EscapeAttributeName($this->nodeIdName)."=?";
		$query=$this->pdo->prepare($sql);
		$query->execute(array($active,$item[$this->nodeIdName]));
	}
//....

C'est bien la peine d'utiliser l'overhead de PDO pour laisser passer ça

[TiranusKBX]

Tien moi aussi j'ai fait ma propre classe en PHP pour le traitement des base de données, un code que je réutilise tout le temps
et qui me fait gagner bien du temps avec un résultat bien plus modulable qu'avec pdo seul

Sinon pour la réutilisation de code il faut juste voir quels sont les parties que l'on à besoins de réutiliser souvent et l'on en fait des classe

[black_soul]

L'avantage, c'est vu que tu as centralisé l'accès à tes données, tu peux directement corriger une injection SQL potentielle :

C'est bien la peine d'utiliser l'overhead de PDO pour laisser passer ça

Je n'y avais pas pensé, mais cette variable n'est de toute manière attribuée que dans mon code en dur et ne peut pas être attribuée dynamiquement par une variable $get par exemple. Si quelqu'un arrive à la modifier, c'est que rien ne l'empêche d'aller mettre sa propre requête complète

[Cincinnatus]

Au niveau du code il sera toujours difficile de détecter les duplications : du code légérement diffférent peut faire la même chose (même si des outils comme checkstyle peuvent aider).

Les créateurs de Feature-Driven Development (FDD) ont mis l'accent sur la conception, le modèle.
En effet, au niveau de la modélisation la réutilisation est effectivement beaucoup plus aisée, la duplication plus claire et le code résultant plus propre.

[pcaboche]

Dommage que la densité de trolls par ligne soit aussi élevée dans ton message car le fond était plutôt intéressant,

Merci.

la programmation fonctionnelle ayant en effet un très net avantage dans la réutilisabilité des algorithmes élémentaires.

C'est clair.

Aussi, quand je lis "l’un des principaux concepts faisant l’éloge de la programmation orientée objet était la réutilisation", je trouve que c'est un peu exagéré (limite trollesque), d'où ma réponse (pas mal exagérée, je l'admets).

Après je ne dis pas qu'il faut tout jeter pour faire de la programmation fonctionnelle, mais juste que de s'essayer à d'autres paradigmes permet de voir d'autres manières de penser. Même si on ne voit pas le bénéfice immédiat, ça a un effet positif sur notre manière d'appréhender certains problèmes (ex : la question de la réutilisabilité).