(Courriels de diversion: <t-shirt@concretiseront-defraîchirent.com> <decantant@evenement-sot.com> <indemnite@revigorent-panache.com> <reversons@tisserions-festoyiez.com> <epileront@refourguer-retrocediez.com> <reexaminant@approcheront-baignades.com> <alliance@confineraient-traita.com> <eludais@cloisonnant-watt.com> <eclairera@muscats-tremblotantes.com> <flanchera@cupidement-adonnes.com> )
Le 11 Juillet, Rossel écrit : > Personnellement, je suis tres interesse par les langages tres oriente > objet. [...] > Mais ca me parait un super moyen de faire de la reutilisation de code. Ben ça dépend, à mon avis. Réutiliser pour réutiliser, ça ne me semble pas être un objectif en soi. Je crois qu'il faut se demander pourquoi on souhaite réutiliser du code. Pour ma part, je vois plusieurs objectifs : 1 - faire des économies de développement ; 2 - faire des économies de test ; 3 - faire des économies de maintenance. Sébastien Renard (dans <396c05c3.298d.0@meloo.com>) aborde l'utilisation de composants tout faits (et il oublie au passage Corba, et même des choses plus traditionnelles comme Motif et tous les autres trucs réutilisables lors de la compilation). Faut se méfier, quelque part. Réutiliser du code n'a pas que des avantages. Par exemple, mal maîtriser le point 2 a coûté la première fusée Ariane 5 (mais a rapporté un beau feu d'artifice ; un poil cher quand même, à mon avis). De plus, tu es contraint par les interfaces et les performances du code à réutiliser. Ce qui veut dire que le problème de la réutilisation de code est presqu'entièrement concentré dans la fabrication du code réutilisable et dans sa documentation. Une fois la problématique ainsi posée, tu comprends que la réutilisation de code n'est pas forcément liée à l'utilisation d'un langage orienté objet. Ce que tu réutilises le plus, et le plus facilement, ce sont les bibliothèques de bas niveau (bibliothèque C et interfaces de l'OS par exemple). Après, tu peux souhaiter personnaliser les comportements réutilisés : par passage de paramètres ou par réflexes (callbacks). Et tout ça, avec des langages "classiques". Et s'ils ne supportent pas directement les fonctionnalités nécessaires (par exemple COBOL pour les réflexes), il peut exister des générateurs de code qui permettent de faire ça (après tout, un générateur de code, ce n'est jamais qu'un compilateur qui te permet de t'exprimer dans un autre langage que le langage cible). Mais tu es limité par la "variabilité" construite a priori dans le code réutilisé. Sur ce thème, les articles de Richard Gabriel dans les JOOP de 1993 sont éclairants (je chercherai les références exactes si ça intéresse quelqu'un ; suffit de demander). Alors, qu'est-ce que t'apporte un langage orienté objet de ce point de vue ? D'abord une intégration de certains contrôles d'utilisation de la variablité (par le compilateur s'il s'agit de langage à typage statique comme C++ ou Java, ou par le support d'exécution s'il s'agit de langage à typage dynamique comme Smalltalk ou CLOS ; voire les deux, s'il s'agit de cadres de travail (framework) comme Corba, Com). Ensuite un cadre de travail qui te permet de mieux classifier les différents degrés de variabilité d'un code à réutiliser. Et de clarifier tes concepts : un truc se comporte comme un machin, mais il fait une certaine chose différemment (la classe truc hérite de la classe machin avec redéfinition de la méthode chose avec liaison dynamique). > Et je trouve assez etonnant que l'oriente objet ne s'impose pas comme le > vecteur des logiciels libres, en associant aux licences libres une > facilite de reutiliser le code. Je n'ai pas cité la manière la plus courante de faire de la réutilisation : le copier/collez. Elle répond au point 1, mais n'est pas top du point de vue du point 2, et franchement détestable pour le point 3. Tout dépend des priorités du moment. Mais il y a également un coût associé à la réutilisation de code hors copier/coller (et génération de code) : la généricité entraîne la prise en compte de cas non pertinents pour l'application visée, et donc du code inutile dans le contexte (et nuisant donc au rendement de l'application). (Quand je pense que Sébastien pensait avoir fait long ...) -- Marc Thirion | Toulouse, France Un Travail pour Chacun : http://www.multimania.com/untravailchacun/ Marc.Thirion@ISOscope.com : http://www.ISOscope.com/Pérennité des logiciels et des systèmes --------------------------------------------------------------------- Aide sur la liste: <URL:mailto:linux-31-help@savage.iut-blagnac.fr>Le CULTe sur le web: <URL:http://www.CULTe.org>