Juste par curiosité, qui s'est amusé à développer un ensemble de composants réutilisable de manière à capitaliser pour l'ensemble de ses développement ??
Ce serait cool également d'avoir une idée de ces composants : composants graphiques, accès base, implémentation de patterns ...
Et dans quel langage ??

Y'a personne qui pense à ne pas réinventer la roue à chaque développement ?? Ben alors, ça sert à ça aussi l'objet !!

C'est pour ça que je ne m'amuse pas à les redevelopper : j'utilise ceux qui ont déja été fais  

C'est bien bô de parler de couche réutilisable, mais je trouve ça un peu pompeux.
 
tout développeur qui se respecte fait des fonctions, et il les réutilises d'un projet sur l'autre (enfin moi c'est ce que je fais).
 
M'enfin, si c'est ça que tu appelles une couche réutilisable
 
C'est un peu le B-A-BA non?

Non, je voyais juste une couche permettant de donner un comportement précis à des classes de base ex : couleur de bouton, abonnements automatiques, couche de persistence spécifique ...
Tout cela permettant de :
 
1 - avoir un comportement standard pour l'ensemble des applications.
2 - permettre la maintenance / l'évolution de cette couche sans impacter l'ensemble des programmes
 
Un exemple ?? Ben tient, concernant le fonctionnement même d'une JVM et bien le problème c'est que c'est gourmand en fonctionnement ça => environ 20 à 30 Mo qui partent en fumée. Et bien une couche de démarrage d'application permettant de faire exécuter plusieurs programmes JAVA dans une même JVM permet aux développeurs de bénéficier d'un mécanisme n'existant pas dans le JDK sans avoir a maitrise celui-ci.
Bon, ce passage était juste une mise en bouche, en fait pour un fonctionnement cohérent de plusieurs applications dans une même JVM et bien plusieurs problèmes existent à commencer par la modalité des fenêtre => une modalité classique ferait que l'ouverture d'une fenêtre modale bloque l'ensemble des applicaitons, pas bien !! Du coup, vu qu'une couche complète a été développée et utilisée pour l'ensemble des applications, il suffit de modifier le comportement des objets de la couche pour permettre à une appli lambda de fonctionner avec d'autres appli dans une meêm JVM.
 
En fait, et pour conclure vraiment, ce que je demandais c'est si quelqu'un c'était tout d'abord implémenté une ensemble de composants dits "de base" et que seuls ces composants seraient utilisés dans le développement des applicaitons !!
Je n'appelle pas ça du B-A-BA car je suppose que, dans la mesure où je demande, par exemple, à quelqu'un de modifier le comportement d'un simple label dans toutes ses applications et bien combien n'auront qu'un objet à modifier plutot que tous les labels de toutes les applications ... Là ça s'appelle de l'abstraction facilitant la maintenance et la standardisation (toutes les applis ont un comportement strictement identique).
 
Alors, ça vous cause plus ....
 
Et puis, je vais peut être passé pour un puriste mais je ne parlerai pas de fonction mais des composants ayant un comportement !!
 
Seblamb : les composants que tu réutilise, ils correspondent totalement à tes attentes ?? L'implémentation d'une table par exemple ne te semble pas compliqué en ne le faisant qu'avec le JDK, as-tu pensé que tu pouvais grandement faciliter l'implémentation d'un tel composant en capitalisant dans un objet à toi quelque chose de plus simple ??

Salut !
J'ai des couches réutilisables & réutilisées (si, si...) en powerBuilder. j'utilise les couches fournies par PB, enrichies ou corrigées. La même couche sert à plusieurs applis différentes.

C'est dans un contexte professionnel ou personnel ??
La customisation que tu as fait porte pricipalement sur quels types d'objet (graphique, accès base ...) ??

Salut
Dans un contexte professionnel.
Je sais pas si tu connais Powebuilder [pb], mais faut savoir que pb est livré avec une hiérarchie de classes (les powersoft foundation class [pfc] - original, non   ) à 2 niveaux : 1 niveau qui contient du code, & 1 niveau vide juste en dessous dans lequel tu peux rajouter du code "général". Ces pfcs couvrent grosso modo l'inteface Windows, + la connexion aux bases de données & de nombreux utilitaires - le tout + ou - bien, évidemment.
Pour ce qui est des utilitaires (ex. : conversion de types de données), c'est pas compliqué d'avoir du code réutilisable ; lorsque t'ajoutes 1 fonction, tu pourras t'en servir dans 1 autre appli si tu utilses les mêmes classes.
Pour le reste, ce que j'ai pu faire est :
  - gestion de préférences d'aspect pour des champs de saisie,
  - automatisation du contrôle de champs obligatoires,
  - système de duplication de données d'une base distante sur une base locale au poste client (pour des données qui sont des "tables de référence" ; permet d'accélerer l'affichage de libellés ou la construction de listes pour faire des choix),
  - quelques fonctionnalités pour la connexion aux bases de données (vider 1 table par ex)...
 
En fait, avec ce genre de système, tu arrives a améliorer le comportement ou les fonctionnalités de classes fournies, soit 1 peu, soit beaucoup selon les cas ; j'ai rajouté des fonctions ou événements 1 peu partout, donc ça concerne de nombreux thèmes. Des couches développées entièrement & ajoutées, j'en ai très peu.
globalement, j'arrive cependant à réutilser du code sur des applis
  - qui n'ont rien à voir les 1 avec les autres,
  - qui attaquent des bases de données ui n'ont rien à voir les 1 avec les autres.
 
& c'est déjà pas mal...

J'utilise des objets en php que je capitalise, mais ça reste "que" du dèvelopement web  

En effet c'est déjà bien d'avoir un minimum et surtout de penser à capitaliser ...
Pour détailler un peu plus, de mon coté c'est en JAVA :  
- couche d'abstraction par rapport aux composants graphiques JAVA (de manière à être indépendant des classes de bases et de pouvoir en changer : au début on n'utilisait pas forcément des classes graphiques du JDK mais de certaines bibliothèques parallèles) ce qui nous a permis de changer le composant de base sans réimplémentation
- implémentation d'un template MVC (Modèle, Vue, Controleur)permettant de cloisonner le graphique, les données et le comportement pour chaque composant et conteneur
- refonte de la gestion des événements, aisée grace au MVC, nos événements étaient déjà traités dans un composant dédié par composant
- refonte de la gestion de modalité
- module de persistence CICS ou JDBC
- onjets persistents de base pour les objets métiers
and many more ...
- amélioration de la gestion mémoire en libérant au maximum les références entre objets + module de forçage de garbage => gros gain mémoire car le garbage c'est gentil mais peu performant sans libération de liens.
 
Tout ceci dans un contexte professionnel avec une quinzaine d'applications utilisant ces classes de base.
 
Ce qu'il reste à faire : un peu de propre (y'a certaines implémentations un peu lourdes et/ou peu "Objet" ), beaucoup de doc mais globalement ça commence à être super stable.
 
Voilà à peu près tout !!

>Bandenabos
Tes applis, elles ont des rapports entre elles ou bien elles sont totalement indépendantes les unes des autres ?
 
J'élargis le sujet :
Pour modéliser vos objets, vous utilisez des outils / méthodes / langages de définition particuliers ?
Vous utilisez des liens "objet" dans vos modèles de bases de données ?
Si tel est le cas, comment vous représentez ces liens objet en relationnel ? (ok, je postule que des sgbd OO ne sont pas utilisés).

Les applications sont indépendantes mais certains modules sont réutilisés. En fait des modules (ex : gestion de personne physique) est à la charge d'équipes s'occupant d'une application.
 
Concernane la DB et bien oui c'est du relationnel. On a donc créé un outil de génération d'objets persistants (en Java) et une bibliothèque IBM pour la création dans DB2 via CICS.
 
La modélisation est objet en UML avec l'outil UML Suite de chez Mr Télélogique (anciènement COOL GEX de chez Sterling).

J'utilise des Pampers, c'est pas trop mal pour ça...
 
Désolé, je pouvais pas m'empêcher