Discussion :

[Magicien d'Oz]

Salut,

Alors voilà le truc. La dernière fois, j'ai fait une classe avec une méthode main et plein d'autres méthodes super pratique pour le calcul matriciel et vectoriel. Des simples boucles sur des tableaux, mais pratiques. Bref, là je vais faire un autre programme qui va aussi manipuler des matrices et j'aurai voulu réutiliser toutes ces méthodes sans faire un copier coller. Comment-puis je faire ? Ya t il possibilité de faire un genre de package assez simplement ?

Merci et bonne journée.

[sozie9372]

Tu as 2 possibilités...
Soit tu ajoutes ta classe "Utile" a ton projet et tu crées un objet "Utile". Tu pourras ainsi appeler les méthodes publiques de cet objet sans avoir à faire de copier/coller.
Soit tu crées un jar contenant ta classe "Utile" que tu importeras dans le classpath de ton projet. Tu pourras alors, comme précédement, créer un objet "Utile" grâce auquel tu appeleras les méthodes publiques de la classe "Utile"

[KiLVaiDeN]

Salut,

Il va falloir modifier ta Classe existante, pour la transformer en une sorte de librairie de fonctions.

Pour ça, par exemple, tu la nommeras "MatriceUtilities.java", et elle contiendra des méthodes "static" qui seront donc accessibles directement, sans instancier d'objet. De toutes façons je pense qu'elles sont déjà en static, si tu les utilisais directement dans le main. Tu appelleras les méthodes par : MatriceUtilities.calculMatrice(); par exemple.

Ensuite, pour l'inclure dans un nouveau projet, tout dépend de l'outil que tu utilises pour coder. Sous Eclipse par exemple, tu pourras faire de la dépendance de projet, en créeant un projet qui serait ta librairie ( contenant donc ta classe de Matrices ).

Une façon plus propre de faire cela ( je la signale quand même ) serait de faire de ta classe un singleton (cf le net pour savoir ce que c'est).

Ensuite, tu appellerais ta méthode avec MatriceUtilities.getInstance().calculMatrice();

A+

[Magicien d'Oz]

Ok, merci beaucoup.

Mais juste pour chipoter, il n'y a pas moyen d'éviter d'écrire à chaque fois "MatriceUtilities.", on peut pas mettre juste le nom de la méthode ?

[KiLVaiDeN]

Le fait est que Java est un langage par objets.

Donc quand tu fais appel à une méthode, il est courant et normal ( même obligatoire dans la plupart des cas ) de nommer l'objet qui contient la méthode, ou dans le cas de méthode statiques, de la classe.

Donc dans ton cas, oui il faudra toujours préciser MatriceUtilities.

Par contre, dans le cas que j'ai donné de l'utilisation d'un singleton, tu peux avoir quelque chose de plus compacte :

Code :

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

1
2
MatriceUtilities mu = MatriceUtilities.getInstance(); // Récupération de l'instance
mu.calculerMatrice();

Tu es toujours obligé d'utiliser le nom de l'objet ici, mais il est plus court, tu pourrais le nommer comme tu veux.

[Magicien d'Oz]

ok et merci

Au vu de l'utilisation que je vais en faire, je pense que je vais juste utiliser la première solution : un fichier regroupant toutes les méthodes appelée à chaque fois par MatriceUtilities.SommeMatrice par exemple.

Merci

[le y@m's]

Ok, merci beaucoup.

Mais juste pour chipoter, il n'y a pas moyen d'éviter d'écrire à chaque fois "MatriceUtilities.", on peut pas mettre juste le nom de la méthode ?

C'est possible depuis Java 5 avec l'import static
cf FAQ : [Java 5.0] Qu'est-ce que l'import static ?

[KiLVaiDeN]

Bien vu, le y@m's

Mais l'utilisation d'un singleton est bien plus puissante de toutes façons que celle d'une classe statique : en effet, on peut alors avoir un vrai objet en mémoire, qui aura ses attributs et ses propres liens, vers d'autres objets, je pense par exemple aux systèmes de Logs, aux liens vers d'autres objets métiers, etc..

Dans le cas d'une classe statique, ces liens seraient à refaire à chaque appel de la méthode.

[le y@m's]

Bien vu, le y@m's

Mais l'utilisation d'un singleton est bien plus puissante de toutes façons que celle d'une classe statique : en effet, on peut alors avoir un vrai objet en mémoire, qui aura ses attributs et ses propres liens, vers d'autres objets, je pense par exemple aux systèmes de Logs, aux liens vers d'autres objets métiers, etc..

Dans le cas d'une classe statique, ces liens seraient à refaire à chaque appel de la méthode.

Ce que tu dit est vrai mais je ne pense pas que dans ce cas un singleton sois utile. En effet, les méthodes n'ont, a priori, aucun lien entre elles et sont toutes static. De ce fait il me parait inutile de vouloir construire une architecture ayant un semblant d'objet alors que l'on est dans une logique toute procedurale.
Le singleton trouve toute sont utilité dans le cadre d'une classe de type factory mais n'apporte, ici, rien du tout (aucun lien entre les differentes méthodes, aucun attribut n'est rattaché à une instance (que du static)).

Personnellement j'ai plusieurs classes de ce genre (avec uniquement des méthodes static) et je me contente de déclarer le constructeur par défaut private afin d'empécher l'instanciation de la-dite classe, ensuite un simple import static et le tour est joué .