Discussion :

[pcaboche]

L'abus de réuse... ça fait des kangourous tueurs!

En même temps, c'est clair que conceptuellement parlant, un kangourou est tout naturellement une sous-classe de soldat d'infanterie.

Il y a plusieurs années de cela, j'avais eu une question similaire lors d'un entretien d'embauche (une question piège où le candidat est tenté de dériver une classe qui n'a conceptuellement rien à voir, juste pour pouvoir réutiliser certaines propriétés et méthodes). Visiblement, j'étais le seul à ne pas tomber dans le panneau (comme quoi ces histoires de réutilisabilité par simple héritage + polymorphisme, ça entraine des raisonnements bizarres chez pas mal de monde, que ce soit en France, en Australie ou ailleurs...). Finalement j'ai signé chez une autre compagnie où le projet me paraissait beaucoup plus intéressant (et puis j'avais pas envie de travailler pour une SSII française qui promet monts et merveilles mais où c'est jamais suivi des faits).

[pcaboche]

Bon, ce que je vais dire, c'est un peu de la provocation, mais il y a aussi un nombre de cas non négligea&ble où on a de la réutilisabilité inutile. On conçoit l'APi de la mort, on brainstorme comme des fous pour avoir un fonctionnement modulaire, des façades et tout le toutim. Mais le truc, c'est que ce que fait le composant n'a pas d'intérêt dans un autre contexte, et il n'est tout simplement jamais réutilisé. Concevoir du code pour qu'il soit réutilisable a un coût, comme tout. Il faut quand même se demander à un moment si la réutilisabilité a vraiment un intérêt.

Concevoir une API réutilisable, c'est très compliqué (ou, comme tu le soulignes, ça ne se justifie que très rarement).

En revanche, au sein d'une même API, on retrouve souvent du code qui pourrait être réutilisé d'une façon ou d'une autre. Combien de fois n'ai-je pas vu du code copier-coller au sein d'un même programme ? (et souvent même, par le même développeur).

En programmation, j'ai quelques principes :
- le copier-coller, c'est mal ("don't repeat yourself")
- "small is beautiful" (ou "do more (features) with less (code)")

Je trouve qu'il est plus simple de procéder comme suit :
- à chaque fois que que l'on est tenté de faire du copier-coller, on doit se demander comment pouvoir rendre le code plus réutilisable
- une fois qu'on a trouvé une solution permettant de réutiliser du code a fait ses preuves localement (au sein d'un même programme), alors on peut se demander s'il est possible (et viable) de l'appliquer dans d'autres contextes

L'inverse (réfléchir à des composants réutilisables à l'avance) est très compliqué.

Cela vient en partie du fait que le cerveau humain est le fruit de millions d'années d'évolution dans la reconnaissance de motifs (pattern recognition), et qu'il est très efficace dans ce domaine. Ce cerveau qui nous a permis il y a des milliers d'années de comprendre pourquoi certaines plantes poussent à certaines saisons, nous permet aujourd'hui de comprendre pourquoi certains motifs de programmation reviennent invariablement et comment factoriser ce code.

[Médinoc]

L'abus de réuse... ça fait des kangourous tueurs!

"Ce sera évidemment répété, amplifié, déformé..."

[Mister Nono]

Bonjour,

Effectivement la réutilisabilité du code demande une abstraction technique assez poussée mais génère des programmes fiables dans le temps et améliore ensuite significativement le cycle de vie d'une application.

Mais cela demande un petit investissement supplémentaire en temps et dans des personnes compétentes : nos chères Sociétés françaises voient à très court terme. Faire du code réutilisable est donc souvent mal vu et peut couter la place de son auteur qui soit disant travaille un peu moins vite, maîtrise trop bien le code (ça c'est pour le chef jaloux qui en sait moins sur le code que vous), ne fait pas comme les autres (ça c'est pour l'équipe qui brille une médaille auprès du chef jaloux à coup de : je travaille plus vite avec la commande copier-coller)...

Pauvre France.

S'il vous plait : codez correctement, rehaussez le niveau de l'ingénierie. C'est simple, ce type de billet ne devrait pas avoir lieu d'être si tout le monde travaillait correctement. Mais ça c'est une utopie.

[helicene13]

La POO est un rêve merveilleux qui ne peut se réaliser que dans des conditions nord-coréennes, associées au taylorisme le plus rigoureux. Il faut une discipline de fer et un "gardien" des objets omniscient, omnipotent et impitoyable pour que ça marche.

[Immobilis]

Salut,

Il faut une discipline de fer et un "gardien" des objets omniscient, omnipotent et impitoyable pour que ça marche.

+1

Et c'est son boulot si il est chef de projet. En tous les cas c'est celui du responsable technique (quand y'en a un). A mon avis, Scott Westfall devrait se remettre en question.

[lysandro]

En même temps, c'est clair que conceptuellement parlant, un kangourou est tout naturellement une sous-classe de soldat d'infanterie.

Logiquement parlant, la conclusion est un peu rapide.

Dans la présentation faite, on sait que les kangourous sont neutres : ils ne sont pas la cible des hélicoptères. Donc, dans ce cas, même en tant que soldat d'infanterie, ils n'avaient aucune raison d'ouvrir le feu.

Avant de conclure, il nous faut donc nous poser la question : pourquoi ont ils tiré ?!

Il semble évident dés lors, que l'erreur n'est nécessairement pas d'avoir sous-classé le soldat d'infanterie, mais plutot d'en avoir fait un ennemi.
Il faut se méfier des a priori, qui sait jusqu'où peut aller un kangourou bien énervé.

[imikado]

Ca dépend des projets: pour nos batchs on a réussi à capitaliser un maximum en créant des composants utilisés par tous

Pour le web, certains frameworks proposent une logique plus ou moins DRY permettant de capitaliser

Personnellement, dernièrement je viens d'ajouter au téléchargement un module générique à customiser pour ses besoins pour pouvoir réutiliser et ainsi capitaliser sur la conception de tableau,: http://mkframework.com/telechargerModule_table.html

[black_soul]

Logiquement parlant, la conclusion est un peu rapide.

Dans la présentation faite, on sait que les kangourous sont neutres : ils ne sont pas la cible des hélicoptères. Donc, dans ce cas, même en tant que soldat d'infanterie, ils n'avaient aucune raison d'ouvrir le feu.

Avant de conclure, il nous faut donc nous poser la question : pourquoi ont ils tiré ?!

Il semble évident dés lors, que l'erreur n'est nécessairement pas d'avoir sous-classé le soldat d'infanterie, mais plutot d'en avoir fait un ennemi.
Il faut se méfier des a priori, qui sait jusqu'où peut aller un kangourou bien énervé.

La logique aurait plutôt été :

Être vivant => Humain => Soldat
Être vivant => Animal => Kangourou

[souviron34]

Excusez-moi de ne pas avoir tout lu, juste la première et la dernière page

Mais en gros c'est un pe ce que je disais dans les débats généraux il y a quelques années sur "objet vs procédural" et autres...

Il N'Y A PAS DE SOLUTIONS MIRACLES..


Comme le dit :

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.

La déification du OO a empêché que ce soit les enseignants, mais aussi les programmeurs ou les CP de voir les écueuils.. Que ce soit en terme de complexité, de maintenance, ou de ré-utilisabilité... La création de classes à tout va, de méthodes privées, de surcharges, etc, au lieu de faciliter - ce que cela peut faire à petite échelle - complexifie énormément pour de grands projets... Et rend au minimum AUSSI complexe que les autres pradigmes la réutilisabilité, voire plus....


Quand on voit que l'installation de Java nécessite plus de 65 000 fichiers (faites le test avec un antivirus, vous verrez le nombre de fichiers parcourus) on se dit qu'il y a forcément un bug quelque part : c'est (beaucoup) plus que le volume de fichiers nécessaire pour des OS complets... (sauf Windows, bien entendu)


Là on est environ 15 à 20 ans après l'apparition de la mode et du Dieu, et environ 10 ans après l'apogée de ce mouvement. On arrive donc dans le début de la période de maintenance et d'évolution des grosses applis, et poffff comme par magie les problèmes commencent à apparaître

Donc rien de nouveau sous le Soleil, simplement un reset des compteurs pour revenir à la normalité : il n'y a a pas de panacée universelle, et toute chose possède des inconvénients..

Yeaah !!! Grande découverte...

[bretus]

Que ce soit en terme de complexité, de maintenance, ou de ré-utilisabilité... La création de classes à tout va, de méthodes privées, de surcharges, etc, au lieu de faciliter - ce que cela peut faire à petite échelle - complexifie énormément pour de grands projets... Et rend au minimum AUSSI complexe que les autres pradigmes la réutilisabilité, voire plus....

Ca, c'est la base de l'OO, base qui s'avère insuffisante pour permettre une véritable de ré-utilisabilité. Essayons de voir à quoi ça sert et comment ça a évoluer :

1) Le progrès des classes/structures en tant qu'agrégateur de variables

Avec la notion de structure, on a arrêté de péter les prototypes des fonctions et procédures à chaque variable supplémentaire nécessaire.

Il fallait reprendre tous les appels quand on passait de ceci

Code :

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

1
2
maFonction( a, b ) ;

à ceci

Code :

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

1
2
maFonction( a, b, c ) ;

En passant de ceci

Code :

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

1
2
3
4
5
struct MaStruct {
    a : double ;
    b : double ;
};

à ceci

Code :

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

1
2
3
4
5
6
struct MaStruct {
    a : double ;
    b : double ;
    c : double ;   
};

les appels à

Code :

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

maFonction( s : MaStruct ) ;

restent inchangés!

2) L'idée des getters/setters

Les getters/setters sont dans la continuité de ce qui précède. Quand on s'est mis à imbriqué des structures, on a voulu pouvoir changer la logique interne des classes.

3) Polymorphisme et interface

On en a eu marre de faire évoluer des codes du style :

Code :

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

1
2
3
4
5
6
7
8
if ( g est un point ){
   affichePoint( g ) ;
}else if ( g est un ligne ){
   afficheLigne( g ) ;  
}else{
   // on ne connait pas
}

On est passé à

Code :

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

1
2
g.dessine( renderer ) ;

En bonus, on peut ajouter la notion de polygone, de courbe de Bezier, etc. sans péter les codes existants.

4) Les patrons de conceptions

Seules, les règles de bases de la P.O.O. ne permettaient pas de rendre les codes ré-utilisables.

Il ne suffisait pas d'avoir des getters et des setters pour modifier le fonctionnement d'un algorithme sans modifier le code d'origine. Par contre, si on commençait à mettre en paramètre de ces algorithmes des interfaces pour les stratégies de calcul, ça devenait possible.

Qu'est-ce qu'ils ont fait de si génial au juste? Ils ont posés un nom sur ces principes : Le design pattern Strategy pour l'exemple précédent.

Connaissant ce concept, vous faites un algorithme de plus court chemin, vous vous rendez compte que les stratégies Disjktra/A-star/... interviennent au niveau de la sélection du prochain sommet à visiter, vous mettez en paramètre un NextVertexFinderStrategy et hop : D'autres peuvent programmer des variantes sans re-compiler ou modifier vos codes.

Mieux, s'ils connaissent la terminologie, le suffixe "Strategy" leur sautera aux yeux : Ils gagneront du temps pour comprendre l'organisation de votre code.


5) Des patrons de conception aux frameworks

Les bases étaient plantées avec ce qui précède, ils restaient à mettre en place des cadres pour organiser ces concepts au sein d'application et mettre en place les grandes lignes des architectures.

Des frameworks formant des assemblages ont vu le jour avec certains points communs :
- La gestion des initialisations des objets et les dépendances entre ces derniers est assurée par de l'injection de dépendance (Quand on doit progressivement envoyer des mails, écrire des logs dans des fichiers ou en base en fonction d'une configuration, etc.)
- La gestion des traitements multiples déclenchés par un changement d'état est guidée par la présence d'un mécanisme de gestion d'événement et c'est là que le setter devient utile :

Code :

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

1
2
3
4
5
MonObject::setState( state ){
    this.state := state ;
    trigger( this, "statechanged" ) ;
}

Maintenant, on peut dire : "Ok patron, j'envoie un mail quand l'état change (il me suffit d'ajouter un écouteur). Ok patron, je dessine le graphique quand l'état change (deuxième écouteur)..."
- ...

Est-ce que c'est l'ultime solution? J'en doute car on voit désormais des serveurs implémenter ces patrons de conception (RabbitMQ et sa pile de message) : On n'assemble plus des classes implémentant des patrons de conception, on assemble des serveurs qui s'en inspire...

Quand on voit que l'installation de Java nécessite plus de 65 000 fichiers (faites le test avec un antivirus, vous verrez le nombre de fichiers parcourus) on se dit qu'il y a forcément un bug quelque part : c'est (beaucoup) plus que le volume de fichiers nécessaire pour des OS complets... (sauf Windows, bien entendu)

Le principe "une classe" = "un fichier" est le cœur du chargement dynamique des classes. Forcément, ça fait du nombre.

Ensuite, pour avoir passer mon temps à faire des recherches dans des codes en C pour trouver l'emplacement du code de telle ou telle fonction, faute de convention d'organisation des sources, je peux vous dire que je préfère largement fouiller dans Java...

Seulement, pour comprendre l'organisation de Java, de DotNet et des principaux framework modernes : Il faut avoir en tête les principaux patrons de conception et leurs rôles.

Sans ça, on s'énerve contre la complexité sans comprendre à quoi elle sert. Pire, on les utilise mal et on monte des monstres (concrètement, on essaie de garder le niveau de généricité d'un framework là où ça n'est pas nécessaire, c'est à dire dans une application)...


PS : Poser des noms, des définitions, ça ne vous rappelle rien en mathématique? A mon sens, un bon code orienté objet masque la complexité algorithmique dans des structures : On passe d'une démonstration de 2 pages à une démonstration élégante de quelques définitions, quelques lemmes et un assemblage. La base : On ne code pas une indexation propre à son algorithme, on utilise une structure qui embarque une indexation (set, map, etc.)...

[CodeurPlusPlus]

@bretus : là, tu nous récites une leçon. Serais-tu fraîchement converti à l'OO ? J'y avais pour ma part été converti au milieu des années 90, et j'ai largement eu le temps d'en réaliser les défauts depuis... et même de les "démontrer" (récemment)

[souviron34]

Lol oui je n'ai même pas eu envie de répondre, car la polémique pour la polémique ça me laisse froid...

Ne serait-ce que les 2 premiers exemples, bien peu de personnes les utilisent lors de gros devs. De même, les polymorphismes et patrons sont largement utilisés sans langages OO. Bien sûr pas par les débutants..

Mais pour comparer par rapport au sujet du thread, on ne s'adresse pas à des débutants (enfin, je l'espère)..


L'utilisation de structures, de fonctions enregistrées, de void*, etc (par exemple en C), et d'une pensée fonctionnellement logique permet et des programmations souples et ré-utilisables dans tout un tas de langages non-oo. Et par contre, l'utilisation de frameworks, de langages OO "facilitant" sans réflexion, ou orientant la réflexion (avec des classes à tout bout de champ, et des concepts particuliers au langage (les factory en C++, les .jar en Java..), peuvent créer plus de complexité globale pour une évolution souple et ré-utilisable que ce qui est proclamé partout..

(d'ailleurs comme le traitement par exception)

Bref, comme je disais, on revient smplement à quelque chose de normal : le Dieu a vécu, et est redevenu simple mortel...

Seulement, pour comprendre l'organisation de Java, de DotNet et des principaux framework modernes : Il faut avoir en tête les principaux patrons de conception et leurs rôles.

Donc c'est pas si logique que ça, si il faut se taper des choses comme ça..

D'autre part, je suppose que quand tu parles de codes C tu parles de open-source.... (et plutôt collaboratif). Va fouiller dans le code de Mpeg, de libjpeg, gd (pour gif), des bibliothèques de maths comme Graphics Gems, tu verras que c'est très logique et compréhensible, tout en étant public et libre.. Sans parler de tout ce qui n'est pas public ...

[bretus]

@bretus : là, tu nous récites une leçon. Serais-tu fraîchement converti à l'OO ?

Pour tout te dire, j'ai une formation orientée algorithmie où l'ennemie était l'allocation dynamique.

La plupart des aspects que j'évoque, il m'a fallut quelques années de pratiques pour les comprendre en jonglant entre deux mondes : Le calcul et le développement web.

J'avoue que le mon ressenti est le suivant : Les personnes qui ne connaissent que le premier monde ignorent les apports de l'O.O. et plus précisément des design patterns au second monde.

Ils n'ont pas fait face à des applications immaintenable écrite en PHP procédural sans le moindre cadre : Ils ne peuvent pas percevoir l'intérêt d'un MVC.

Ils n'ont pas fait face à des applications pour lesquelles ce cadre n'était plus suffisant pour maintenir un certain niveau d'organisation des sources car on promenait des loggers, des accès à des bases de données, des systèmes d'envoie de mail, des traitements en tâche de fond, des systèmes de fichiers répartis et bien sûr des myriades de paramètres : Ils ne peuvent pas percevoir l'intérêt de l'injection de dépendance, des gestions événementielles et des piles de message pour homogénéïser le tout.

J'y avais pour ma part été converti au milieu des années 90, et j'ai largement eu le temps d'en réaliser les défauts depuis... et même de les "démontrer" (récemment)

Je n'ai pas dis que l'O.O. était parfaite ni adaptée à toutes les problématiques. Je dis qu'il y a des contextes où son apport est réel.

Je serais preneur de ce que tu as "démontré" et surtout de la réponse a la question suivante : Est-ce que tu considères que l'O.O. est toujours une mauvaise approche?

[souviron34]

en jonglant entre deux mondes : Le calcul et le développement web.

J'avoue que le mon ressenti est le suivant : Les personnes qui ne connaissent que le premier monde ignorent les apports de l'O.O. et plus précisément des design patterns au second monde.

Ils n'ont pas fait face à des applications immaintenable écrite en PHP procédural sans le moindre cadre : Ils ne peuvent pas percevoir l'intérêt d'un MVC.

Vois-tu la superbe restriction que tu fais là ??

Tu parles de procédural, et tu cites PHP et le développement Web.... On ne peut pas dire que ce soit le champ privilégié du procédural.. Entre les applis C, Fortran, Ada, ou Cobol, voire Pascal, il y a un ENORME monde de procédural qui n'est absolument pas touché par ton découpage..

De plus dans MON monde de calcul et de dev d'IHM non Web, mais avec des grosses BDD, les MVC sont totalement généralisés, même en procédural, depuis belle lurette.. Sauf qu'on ne les appelle pas par un nom particulier (c'est ce que je citais plus haut comme "fonctionnellement logique"), qu'on n'en a pas fait une "pierre angulaire" (puisque c'est naturel) et que on l'adapte..

Regarde juste la structure intrinsèque du WWW : des grappes de serveurs... qui la plupart du temps, jusqu'à très récemment, étaient écrits en C. Et dont l'architecture globale n'a nécessité rien d'autre que de la logique, et pas des buzz-words appliqués "à la lettre"...

Je ne connais rien au monde du Web, mais j'ai développé des grappes de serveurs sur le principe du WWW.. Et des IHM où les couches étaient bien séparées.. Les MVC et patterns ne sont rien d'autre que le modèle en couche ISO.. Qui date de la fin des années 70, applicable (et appliqué) dans n'importe quel langage... (et en particulier dans toutes les applis de calculs en C ou Fortran, de même que les applis de gestion en Cobol)..


(et une petite recherche t'indiquera que M$ était le champion pour ignorer ce modèle en couche, qui pourtant avait cours sur toutes les autres machines, jusqu'au début des années 2000... Alors que le modèle en couches avait imposé sous unixoides (et VMS, et MVS) des sockets asynchrones avec un niveau très bas, sous M$ il fallait leur passer un id de fenêtre (WindowHandle)...les serveurs Web M$ jusqu'en 2000 ou 2002 allaient scanner le port toutes les secondes, alors que sous unixoide il attendait d'être réveillé)

[TiranusKBX]

Vus que le sujet semble tourner à la guéguerre n'est-il pas temps de clore le sujet ?
Nous avons bien vus avec les débats que la réutilisation de code ne se limite pas à la POO et que la réutilisation
de code dépend du contexte de développement du programme concerné.
Il fut aussi question du temps passé en dev mais pour cela l'on peur rejoindre le sujet sur la qualité du code
sans temps suffisant l'on code de la m non réutilisable.

Bon maintenant si je reçoit des avec ce discours d'apaisement alors vous nous ferrez passez pour des êtres
aussi cons et vénaux que la plupart des personalités politiques

Edit : merci pour les votes positifs

[Kaamui]

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

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

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

Je n'ai pas tout lu désolé, mais pour le peu que j'ai lu, j'ai l'impression que l'on confond beaucoup réutilisation et réutilisabilité. Egalement je suis étonné qu'on ne parle pas des bonnes pratiques de l'OO, commes les principes SOLID, qui s'ils sont bien respectés offrent une très bonne réutilisabilité.

En effet, je suis d'accord sur le fait que la réutilisation du code réutilisable est assez rare malheureusement. Mais ceci n'est pas une limite de l'OO, c'est une limite humaine, surement liée au fait que les personnes qui font l'organisation d'une entreprises n'ont pas la moindre idée de cet aspect là et de son importance, et ne l'incluent donc pas dans leur façon de concevoir les process.

Je suis sur que si on prend même deux projets CMMI5, le second ne tiendra pas compte du code réutilisable dans le premier, et là, est le souci.

La POO quand elle est bien pratiquée offre réellement une réutilisabilité, une flexibilité, et une robustesse logique et conceptuelle indéniable.

[Iwoks]

Bonsoir,

Beaucoup, trop utilise le clavier avant la tête. (moi le premier )

Donc à la question, faut-il réutiliser son cerveau dans la POO et ses limitations ?

Certes, il faut savoir quels classes existent. Lire les documentations et les faire vivre.
Ensuite, voir pour simplifier la codification selon ses besoins en interfaçant les codes les plus aboutit.
Mode bac a sable, étude de faisabilité. Pour cela, il faut analyser de manière algorithmique et séquentiel les projets dans leurs ensembles.
En déduire, les éléments qui composent le projet. Vérifier l’existence des dits éléments dans les projets voisin.
Organiser des réunion. Programmer la deadline. Et faire référence à Cahier des Charges (type AFNOR)

Exemple existant :
Une équipe 3 personnes développent un gestionnaire de liste
Une équipe 3 personnes développent un gestionnaire annuaire

Quel différence entre une liste et un annuaire ?

Conclusion, le problème n’incombe pas au développeur lui-même. Mais au(x) gestionnaire(s) de projet(s).

Iwoks.