Discussion :

[zaboug]

Bonjour,

je développe une application Web en Java dont une des fonctionnalités va être de faire différents calculs à partir de réponses à des questionnaires. Mais ces différents calculs sont complètement indépendant de mon application web, et ils pourront être réutilisés tel quel dans d'autres applis java de ma boite.
Donc je pensais créer un nouveau projet spécifique au développement de ces calculs pour en faire un jar que j'intégrerai à mon appli web et qui pourrait être utilisé dans toute autre appli Java.

Jusque là tout va bien. Maintenant, je me pose quelques questions pour faire ça au mieux...
Vaut-il mieux :

• Faire un package qui contient toutes mes méthodes accessibles via une interface?
• Créer une classe qui ne contient que des méthodes statiques (une pour chaque calcul) ce qui permettrait de pas avoir à instancier la classe des calculs...

Les deux manières de faire me semble possibles, et je manque d'expérience pour choisir
Auriez vous des conseils à me donner pour répondre à ce genre de problématique?

Merci d'avance

[Fifan31]

Perso, je fournirai une interface exposant les différents services et une implémentation dans ton jar.
Le codage à partir d'interfaces est plus évolutif
Ensuite, tu peux fournir une fabrique; libre aux utilisateur de ta bibliothèque d'utiliser ta fabrique ou de faire de l'injection de dépendance...

[zaboug]

merci pour ta réponse qui tombe à pique : j'allais m'y mettre

Oui, je me disais aussi qu'utiliser une interface serait plus propre, mais le côté injection de dépendance m'embêtait un peu. J'ai jamais utilisé de fabrique, c'est sans doute l'occasion d'aller voir un peu comment ça marche

[EDIT] la lecture de cette discussion sur les fabriques m'a convaincu : je vais mettre en place une interface et son implémentation dans ma librairie, et je vais fournir une fabrique (vu que ça à l'air on ne peut plus simple à mettre en place et tellement pratique)

[tchize_]

J'ai tendance à appliquer le principe du "il est inutile de factoriser trop vite le code".

Aujourd'hui, les IDE sont très puissants pour le refactoring. Il peuvent extraire des interfaces, des factory, remplacer les apples aux classes par des appels aux factories, créer de nouvelles implémentation, en trois clics de souris.

Donc j'ai tendance à appliquer le principe suivant:
1) tout dans une même projet (ton application) codé proprement (pas de mélange entre la présentation et la logique buisness par exemple) mais en ne prenant en compte que des besoins de cette application
2) quand l'application est stable et qu'un deuxième application a besoin de ses fonctionnalité, extraite de la première les fonctionnalité dans une projet à part (refactoring) en s'assurant que la première application continue de fonctionner comme prévu.
3) ajouter dans cette librairie les besoin de l'application 2 en ne cassant pas l'application 1
4) quand c'est fait tu as un truc réutilisable dans d'autres applications, qui ne contiens rien d'excessif et qui s'utilise de manière optimale au regard des besoins réels de tes deux applications

Sinon, on a vite tendance à diviser en plein de petits projets qui ne servent au final que une seule application et où la modularisation a coute du temps en maintenance. (syndrome du "ça peut toujours resservir dans un autre projet mais on ne l'a jamais réutilisé")

[zaboug]

Oui, je suis d'accord sur ce principe.

Mais là, c'est le contexte qui a joué je pense : je suis en contrat d'apprentissage jusque fin Septembre (je ne reste pas dans la boite après) et l'application sur laquelle je travaille est un prototype. C'est pas dit qu'il soit repris après mon départ.
Par contre, le module que je dois concevoir et développer de manière indépendante est issu d'un autre prototype (en php celui là, ils aiment bien les proto dans ma boite ) et mon tuteur m'a demandé de le faire aussi indépendant que possible car il sait que dans tous les cas ce module là sera toujours utile pour ses futures applis à lui (ou à d'autre d'ailleurs)

D'où le fait de faire un autre petit projet pour ce module, d'en faire un jar que j'intègrerai dans mon appli.

[Robin56]

Sinon, on a vite tendance à diviser en plein de petits projets qui ne servent au final que une seule application et où la modularisation a coute du temps en maintenance. (syndrome du "ça peut toujours resservir dans un autre projet mais on ne l'a jamais réutilisé")

J'avoue que cette remarque est importante. Je suis moi-même atteint de ce syndrome et il est vrai qu'on est vite partis dans des délires de modularité (c'est certes très joli après ) mais le temps passé et la maintenance en est rallongée (et ça c'est beaucoup moins beau ).

Ces 4 principes me semblent donc assez efficace.